You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 8, 2020. It is now read-only.
Copy file name to clipboardExpand all lines: packages/composer-website/jekylldocs/reference/js_scripts.md
+303-3Lines changed: 303 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -175,7 +175,7 @@ async function sampleTransaction(tx) {
175
175
176
176
In this example, not only can the specific asset referenced by the relationship in the transaction be referenced using `tx.asset`, the specific participant referenced by the `owner` relationship can be referenced using `tx.asset.owner`. In this case, `tx.asset.owner` would resolve to reference a specific participant.
177
177
178
-
## Promise returns in transaction processor functions
178
+
## Handling asynchronous code and promises in transaction processor functions
179
179
180
180
Similarly to relationships, transaction processor functions will wait for promises to be resolved before committing the transaction. If a promise is rejected, the transaction will fail.
181
181
@@ -285,7 +285,7 @@ async function sampleTransaction(tx) {
285
285
}
286
286
```
287
287
288
-
### Calling {{site.data.conrefs.hlf_full}} {{site.data.conrefs.hlf_latest}} APIs in transaction processor functions
288
+
### Calling {{site.data.conrefs.hlf_full}} APIs in transaction processor functions
289
289
290
290
To call the {{site.data.conrefs.hlf_full}} API in a transaction processor function, the function `getNativeAPI` must be called, followed by a function from the {{site.data.conrefs.hlf_full}} API. Using the {{site.data.conrefs.hlf_full}} API gives you access to functionality which is not available in the {{site.data.conrefs.composer_full}} API.
291
291
@@ -296,7 +296,7 @@ In the example below, the {{site.data.conrefs.hlf_full}} API function `getHistor
296
296
For more information on the {{site.data.conrefs.hlf_full}} APIs you can call in a transaction processor function, see the [{{site.data.conrefs.hlf_full}} API documentation](https://fabric-shim.github.io/ChaincodeStub.html).
@@ -324,6 +324,306 @@ async function simpleNativeHistoryTransaction (transaction) {
324
324
}
325
325
```
326
326
327
+
## Returning data from transaction processor functions
328
+
329
+
Transaction processor functions can optionally return data to client applications. This can be useful for returning a receipt to the submitter of the transaction, or returning an asset modified by the transaction to avoid a separate lookup of the asset after the transaction has been committed.
330
+
331
+
The return data for a transaction processor function must be a valid type, either a primitive type (String, Integer, Long, etc.), or a type modelled using the Composer modelling language - a concept, asset, participant, transaction, event or enumeration.
332
+
333
+
The type of the return data must also be specified on the model for the transaction using the `@returns(Type)` decorator, and the return data must be the last thing returned by the transaction processor function. If you have multiple transaction processor functions for a single transaction, only one of those transaction processor functions can return data. If the return data is missing, or is of the wrong type, then the transaction will fail and will be rejected.
334
+
335
+
### Returning a primitive type from a transaction processor function
336
+
337
+
Here is an example of a transaction processor function that returns a String to a client application.
338
+
339
+
Model file:
340
+
341
+
namespace org.sample
342
+
343
+
@returns(String)
344
+
transaction MyTransaction {
345
+
346
+
}
347
+
348
+
Transaction processor function:
349
+
350
+
/**
351
+
* Handle a transaction that returns a string.
352
+
* @param {org.sample.MyTransaction} transaction The transaction.
### Returning a complex type from a transaction processor function
404
+
405
+
Here is an example of a transaction processor function that returns a concept to a client application. The same code can be modified to return an asset, participant, transaction or event as well.
406
+
407
+
Model file:
408
+
409
+
namespace org.sample
410
+
411
+
concept MyConcept {
412
+
o String value
413
+
}
414
+
415
+
@returns(MyConcept)
416
+
transaction MyTransaction {
417
+
418
+
}
419
+
420
+
Transaction processor function:
421
+
422
+
/**
423
+
* Handle a transaction that returns a concept.
424
+
* @param {org.sample.MyTransaction} transaction The transaction.
Transactions can be modelled as being read-only by specifying the `@commit(false)` decorator. When a transaction is modelled as read-only, the transaction is submitted as normal, and any transaction processor functions for that transaction are executed as normal. However, the transaction is not committed - it will not be endorsed by multiple peers on the blockchain network, nor will it be sent to the ordering service, nor will it publish any events.
570
+
571
+
This feature can be useful when the APIs that client applications can use to read data from the business network are too limited for your use case. These APIs include `get(id)` (get by ID), `getAll()` (get all), `exists(id)` (test existence), and `query(q, params)` (execute a complex query). For example, a client application may wish to get all of the assets across multiple business networks deployed to multiple channels in a single call to the blockchain network. Another example is reducing the result set of a query on the "server" (chaincode) side, before returning the result set to the client application, to reduce network traffic and the load on the client application.
572
+
573
+
Here is an example of a read-only transaction processor function that retrieves a set of assets from the current business network, as well as other business networks, and returns all of the assets to the client application:
574
+
575
+
Model file:
576
+
577
+
namespace org.sample
578
+
579
+
asset MyAsset identified by assetId {
580
+
o String assetId
581
+
o String value
582
+
}
583
+
584
+
@commit(false)
585
+
@returns(MyAsset[])
586
+
transaction MyTransaction {
587
+
588
+
}
589
+
590
+
Transaction processor function:
591
+
592
+
/**
593
+
* Handle a transaction that returns an array of assets.
594
+
* @param {org.sample.MyTransaction} transaction The transaction.
0 commit comments