Composants du package d'API de wrapper

Les packages d'API de wrapper contiennent un fichier d'archive des API de wrapper, un script Terraform pour le déploiement et une collection Postman correspondante.

  • Le fichier d'archive d'API de wrapper est nommé <ChaincodeName>WrapperAPI.zip. Il contient également un script Terraform qui doit être déployé sur 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 de wrapper.

Package d'API wrapper

Le package d'API de wrapper contient un script Terraform qui provisionne toutes les ressources Oracle Cloud Infrastructure (OCI) nécessaires à la création des API de wrapper. Il existe des fichiers de support Terraform supplémentaires et un dossier Oracle Functions pour chaque API. Les packages d'API de wrapper créent les ressources OCI suivantes.

  • Réseau cloud virtuel (VCN) : établit l'infrastructure réseau pour la communication.
  • Applications (Oracle Functions) : déploie des fonctions sans serveur pour gérer la logique d'API.
  • API Gateway : crée la passerelle pour gérer et acheminer les demandes d'API.
  • Déploiement d'API : configure et déploie les API sur API Gateway.
  • Stratégie de déploiement d'API : configure les stratégies IAM nécessaires pour activer l'accès sécurisé.
  • OCI Registry : fournit un registre de conteneurs pour la gestion des images Docker.
Après avoir généré des API de wrapper, si vous souhaitez modifier des variables de configuration, vous pouvez les mettre à jour dans Visual Studio Code, ou vous pouvez extraire le package d'API de wrapper et mettre à jour le fichier terraform.tfvars avec des adresses et des noms de ressource mis à jour, ainsi que le fichier routes.go avec des adresses mises à jour. Modifiez la variable function_paths dans le fichier terraform.tfvars pour mettre à jour une adresse. La variable function_paths définit les adresses 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 tous les routages créés dans la passerelle, y compris le nom de routage, les arguments et s'il existe des arguments facultatifs. Lorsque vous mettez à jour une adresse dans la variable function_paths du fichier terraform.tfvars, vous devez également mettre à jour l'entrée correspondante dans la variable routeData du fichier routes.go, comme indiqué 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 chaîne confidentiel et l'authentification OAuth 2.0. Pour plus d'informations, reportez-vous à Améliorations apportées aux collections Postman.

La collection Postman inclut des adresses et des charges utiles mises à jour pour toutes les API. Le code suivant présente un exemple de charge utile.
{
    "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'administrateur, qui dispose du rôle admin et peut accéder à toutes les demandes POST. Par défaut, cet utilisateur est l'appelant de toutes les demandes POST dans le code chaîne. valeur bc-admin-user
bc-admin-user-password Mot de passe administrateur. valeur bc-admin-user-password
bc-org-id ID d'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 de 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 approbateurs répertorie les pairs spécifiques (par exemple : peer1, peer2) pour approuver cette transaction. ["org1-xyz-abc.blockchain.ocp.oraclecloud.com :20009", "org2-xyz-abc.blockchain.ocp.oraclecloud.com :20009"]
api-gateway-endpoint Adresse de chaque demande, qui sert de chemin de base pour les adresses d'API de wrapper.

S'il y a moins de 50 API, une seule adresse est utilisée. S'il existe plus de 50 API, les adresses sont générées 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 de proxy 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 de jeton d'accès-url
client-id ID client de l'instance Oracle Blockchain Platform. ID de client
client-secret Clé secrète client de l'instance Oracle Blockchain Platform. clé secrète du client
peer Cette variable existe uniquement pour la collection Postman de l'API de wrapper de code chaîne confidentielle, qui nécessite l'en-tête pair pour toutes les API setter et get. org-xyz-abc.blockchain.ocp.oraclecloud.com : 20009

Une fois que vous avez déployé le package d'API de wrapper, la sortie du déploiement de ressource de pile est un objet JSON qui contient les valeurs d'adresse de passerelle. Si vous générez plus de 50 API, plusieurs adresses de passerelle sont générées, une pour 50 API. Vous devez mettre à jour les variables de collecte Postman associées à ces adresses. Les variables relatives aux points d'extrémité de la collection Postman doivent être mises à jour avec les valeurs appropriées à partir de la sortie du déploiement de package d'API de wrapper dans Stack Resource Manager.

Toutes les API setter de la collection Postman de l'API wrapper incluent le paramètre endorsers ou sameOrgEndorser dans la charge utile de la demande. Les informations indiquant les API qui nécessitent le paramètre sameOrgEndorser sont définies dans le paramètre sameOrgEndorserOptionInWrapperAPI du fichier .ochain.json dans le code chaîne. sameOrgEndorser est défini sur True pour les API répertoriées dans ce paramètre dans leur charge utile. Toutes les autres API set incluent le paramètre endorsers à la place. L'exemple suivant illustre le paramètre du code chaîne CBDC de 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 de wrapper, les API indiquées incluent le paramètre sameOrgEndorser en tant que true dans leurs charges utiles.