epistemophiliac/fabric-samples
1
0
Fork 0
mirror of https://github.com/hyperledger/fabric-samples.git synced 2026-06-17 15:35:09 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fix invoke CLI commands in full-stack guide (#1276)

Browse source 
A behaviour change in microfab means that the orderer endpoint needs to
be explicitly specified when using the peer CLI to submit transactions.
Ideally the microfab environment would not require this but the
documented commands do not currently work without this.

This change updates the full-stack-asset-transfer-guide documentation so
that CLI commands include the orderer endpoint explicitly.

Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
This commit is contained in:
Mark S. Lewis 2024-12-07 20:05:30 +00:00 committed by GitHub
parent b11239aac0
commit 15ab2e5da8
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
full-stack-asset-transfer-guide/docs/SmartContractDev/01-Exercise-Getting-Started-ES.md
View file

@ -1,6 +1,6 @@
# Comenzar con un Contrato Inteligente
[ANTERIOR - Introducción](./00-Introduction-ES.md) <==> [SIGUIENTE - Agregar una Función Transaccional](./02-Exercise-Adding-tx-function-ES.md)
[ANTERIOR - Introducción](./00-Introduction-ES.md) <==> [SIGUIENTE - Agregar una Función Transaccional](./02-Exercise-Adding-tx-function-ES.md)
---
@ -36,6 +36,7 @@ just microfab
```
Esto arrancará el contenedor docker (lo descargara automáticamente si es necesario), y adicionalmente escribirá algunos archivos de configuración/data en el directorio `_cfg/uf`.
```bash
ls -1 _cfg/uf
@ -46,7 +47,7 @@ org1admin.env
org2admin.env
```
Un archivo `org1admin.env` es generado que contiene las variables de entorno necesarias para ejecutar aplicaciones _con la identidad de org1 admin_. Una segunda organización es creada, con un `org2admin.env` - esto es para ejercicios más adelante y no es requerido para el actual.
Un archivo `org1admin.env` es generado que contiene las variables de entorno necesarias para ejecutar aplicaciones _con la identidad de org1 admin_. Una segunda organización es creada, con un `org2admin.env` - esto es para ejercicios más adelante y no es requerido para el actual.
Veamos cuáles son las variables de entorno y usemos source para establecer las mismas:
@ -218,7 +219,7 @@ npm install
npm run build
```
Una forma fácil de verificar que el contrato ha sido construido correctamente es generar la metadata del contrato ('Contract Metadata') en un archivo `metadata.json`. Esta es una definición del contrato y de los tipos de datos que éste retornó que es agnóstica a lenguajes. Toma prestado conceptos de OpenAPI utilizados en la definición de REST APIs. Es también muy útil para compartir con equipos que están escribiendo aplicaciones cliente para que conozcan la estructura de la data y las funciones de las transacciones que pueden invocar.
Una forma fácil de verificar que el contrato ha sido construido correctamente es generar la metadata del contrato ('Contract Metadata') en un archivo `metadata.json`. Esta es una definición del contrato y de los tipos de datos que éste retornó que es agnóstica a lenguajes. Toma prestado conceptos de OpenAPI utilizados en la definición de REST APIs. Es también muy útil para compartir con equipos que están escribiendo aplicaciones cliente para que conozcan la estructura de la data y las funciones de las transacciones que pueden invocar.
Como es un documento JSON, puede ser utilizado para crear otros recursos.
El comando que genera la metadata ha sido colocado en el `package.json`:
@ -229,7 +230,6 @@ npm run metadata
Revisa el archivo `metadata.json` generado y observa el resumen de la información del contrato, las funciones de transacciones y los tipos de datos. Esta información puede ser obtenida también en el momento de ejecución y es una buena forma de probar la implementación.
## Desarrollo Iterativo y Pruebas
**Todos los pasos hasta ahora han sido por única vez. De aquí en adelante puedes iterar sobre el desarrollo de tu contrato**
@ -279,7 +279,7 @@ peer chaincode query -C mychannel -n asset-transfer -c '{"Args":["org.hyperledge
Creemos un activo con ID=001:
```
peer chaincode invoke -C mychannel -n asset-transfer -c '{"Args":["CreateAsset","{\"ID\":\"001\", \"Color\":\"Red\",\"Size\":52,\"Owner\":\"Fred\",\"AppraisedValue\":234234}"]}' --connTimeout 15s
peer chaincode invoke -C mychannel -o orderer-api.127-0-0-1.nip.io:8080 -n asset-transfer -c '{"Args":["CreateAsset","{\"ID\":\"001\", \"Color\":\"Red\",\"Size\":52,\"Owner\":\"Fred\",\"AppraisedValue\":234234}"]}' --connTimeout 15s
```
Si estas observando los logs de MicroFab veras que el peer grabo un nuevo bloque al ledger.
@ -316,6 +316,7 @@ Supongamos que queremos cambiar ese mensaje de error por otra cosa.
- Abrir el archivo `src/assetTransfer.ts` en el editor de tu preferencia
- Alrededor de la linea 51, encuentra el string del error y haz una modificación. Recuerda guardar el cambio.
- Compila nuevamente el contrato en typescript:
```
npm run build
```
@ -326,7 +327,6 @@ Puedes arrancar nuevamente el contrato como hiciste antes
npm run start:server-debug
```
Y ejecutar la misma consulta visualizando el mensaje de error actualizado:
```
@ -344,8 +344,8 @@ Puedes entonces arrancar la depuración 'asociada al proceso', y seleccionar el
Recuerda establecer un punto de quiebre al comienzo de la función transaccional que quieres depurar.
Presta atención a:
- VSCode usa node, así que ten cuidado para seleccionar el proceso correcto
- recuerda que existe un límite de tiempo de la transacción cliente/fabric, mientras tengas al chaincode detenido en el depurador, el límite de tiempo sigue 'contando'
- VSCode usa node, así que ten cuidado para seleccionar el proceso correcto
- recuerda que existe un límite de tiempo de la transacción cliente/fabric, mientras tengas al chaincode detenido en el depurador, el límite de tiempo sigue 'contando'
Revisa [Probar y Depurar Contratos](./03-Test-And-Debug-Reference-ES.md) para mas detalles e información en otros lenguajes.

16
full-stack-asset-transfer-guide/docs/SmartContractDev/01-Exercise-Getting-Started.md
View file

@ -1,6 +1,6 @@
# Getting Started with a Smart Contract
[PREVIOUS - Introduction](./00-Introduction.md) <==> [NEXT Adding a Transaction Function](./02-Exercise-Adding-tx-function.md)
[PREVIOUS - Introduction](./00-Introduction.md) <==> [NEXT Adding a Transaction Function](./02-Exercise-Adding-tx-function.md)
---
@ -36,6 +36,7 @@ just microfab
```
This will start the docker container (automatically download it if necessary), and also write out some configuration/data files in the `_cfg/uf` directory.
```bash
ls -1 _cfg/uf
@ -162,7 +163,7 @@ cat << CONNECTIONJSON-EOF > connection.json
CONNECTIONJSON-EOF
```
We can now build the actual package. Create a code.tar.gz archive containing the connection.json file.
We can now build the actual package. Create a code.tar.gz archive containing the connection.json file.
```bash
tar -czf code.tar.gz connection.json
@ -218,7 +219,7 @@ npm install
npm run build
```
An easy way to test the contract has been built ok, is to generate the 'Contract Metadata' into a `metadata.json` file. This is a language agnostic definition of the contracts, and the datatypes the contract returns. It borrows from the OpenAPI used for defining REST APIs. It is also very useful to share to teams writing client applications so they know the data structures and transaction functions they can call.
An easy way to test the contract has been built ok, is to generate the 'Contract Metadata' into a `metadata.json` file. This is a language agnostic definition of the contracts, and the datatypes the contract returns. It borrows from the OpenAPI used for defining REST APIs. It is also very useful to share to teams writing client applications so they know the data structures and transaction functions they can call.
As it's a JSON document, it's amenable to process to create other resources.
The metadata-generate command has been put into the `package.json`:
@ -229,7 +230,6 @@ npm run metadata
Review the generated `metadata.json` and see the summary of the contract information, the transaction functions, and datatypes. This information can also be captured at runtime and is a good way of testing deployment.
## Iterative Development and Test
**All the steps up until here are one time only. You can now iterate over the development of your contract**
@ -279,7 +279,7 @@ peer chaincode query -C mychannel -n asset-transfer -c '{"Args":["org.hyperledge
Let's create an asset with ID=001:
```
peer chaincode invoke -C mychannel -n asset-transfer -c '{"Args":["CreateAsset","{\"ID\":\"001\", \"Color\":\"Red\",\"Size\":52,\"Owner\":\"Fred\",\"AppraisedValue\":234234}"]}' --connTimeout 15s
peer chaincode invoke -C mychannel -o orderer-api.127-0-0-1.nip.io:8080 -n asset-transfer -c '{"Args":["CreateAsset","{\"ID\":\"001\", \"Color\":\"Red\",\"Size\":52,\"Owner\":\"Fred\",\"AppraisedValue\":234234}"]}' --connTimeout 15s
```
If you are watching the MicroFab logs you'll see that the peer committed a new block to the ledger.
@ -316,6 +316,7 @@ Let's say we want to change that error message to something else.
- Load the `src/assetTransfer.ts` file into an editor of your choice
- Around line 51, find the error string and make a modification. Remember to save the change.
- Rebuild the typescript contract:
```
npm run build
```
@ -326,7 +327,6 @@ You can now restart the contract as before
npm run start:server-debug
```
And run the same query, and see the updated error message:
```
@ -344,8 +344,8 @@ You can then start the 'attached to process' debug, and pick the process to debu
Remember to set a breakpoint at the start of the transaction function you want to debug.
Watch out for:
- VSCode uses node, so take care in selecting the right process
- remember the client/fabric transaction timeout, whilst you have the chaincode stopped in the debugger, the timeout is still 'ticking'
- VSCode uses node, so take care in selecting the right process
- remember the client/fabric transaction timeout, whilst you have the chaincode stopped in the debugger, the timeout is still 'ticking'
Look at the [Test and Debugging Contracts](./03-Test-And-Debug-Reference.md) for more details and information on other languages.