corda/docs/source/running-the-demos.rst
josecoll dd3d8ba626 Merge release-v1 onto master (mostly documentation changes) (#1797)
* Updated corda release version to 1.0.0.RC2 (#1641)

* Fixed Simm Valuation Demo Test and enable serializabe java 8 lambdas. (#1655)

* [CORDA-624] Node Explorer on Issuing cash throws MissingContractAttachements exception (#1656)

(cherry picked from commit 27fea4d)

* BIGINT fix for H2 coin selection. (#1658)

* BIGINT fix for H2 coin selection.

* Review feedback

* CORDA-637 Node Explorer shows Network Map Service in Cash Issue dropdown (#1665)

* [CORDA-637] Node Explorer shows Network Map Service in Cash Issue dropdown

* add TODO to remove the hack

* Declare this internal message string as "const". (#1676)

* Merge "A variety of small fixes" into the 1.0 release branch (#1673)

* Minor: improve javadocs in NodeInfo

* Minor: use package descriptions in Kotlin build of api docs too, not just javadocs.

* RPC: make RPCConnection non-internal, as it's a core API. Move docs around so they're on public API not internal API.

* Add an IntelliJ scope that covers the currently supported Corda API.

This is useful when used in combination with the "Highlight public
declarations with missing KDoc" inspection.

* Ironic: upgrade the version of the Gradle plugin that checks for upgraded versions of things.

It had broken due being incompatible with the new versions of Gradle
itself.

* Docs: flesh out javadocs on ServiceHub

* Docs: add @suppress to a few things that were polluting the Dokka docs.

* Docs: mention RPC access in NodeInfo javadoc

* IRS Fixes to bring UI closer to declared financial types (#1662)

* Made problematic CordaRPCClient c'tor private (with internal bridge methods) and added correct c'tors for public use. (#1653)

initialiseSerialization param has also been removed.

* Fixing flow snapshot feature (#1685)

* Fix validating notary flow to handle notary change transactions properly. (#1687)

Add a notary change test for checking longer chains involving both regular and notary change transactions.

* Unification of VaultQuery And VaultService APIs (into single VaultService interface) to simplify node bootstrapping and usability. (#1677) (#1688)

* Identity documentation (#1620)

* Sketch initial identity docs

* Restructure confidential identity docs to better fit structure

* Split confidential identities into API and concepts

* Further expansion on basic identity conceptS

* Merge Party type into api-identity.rst

* Address feedback on written content

* Rework inline code with literalinclude

* Start addressing feedback from Richard

* Clarify use of "counterparty"

* Address comments on key concepts

* Correct back to US english

* Clarify distribution/publishing of identities

* Update changelog around confidential identities

* CORDA-642 Notary demo documentation fixes (#1682)

* Notary demo documentation fixes.

* One of the tables is prefixed.

* CORDA-641: A temporary fix for contract upgrade transactions (#1700)

* A temporary fix for contract upgrade transactions:
during LedgerTransaction verification run the right logic based on whether
it contains the UpgradeCommand.

* Move ContractUpgradeFlowTest away from createSomeNodes()

* Remove assembleBareTx as it's not used

* Update corda version tag to 1.0.0-RC3 (#1705)

* Hide SerializationContext from public API on TransactionBuilder (#1707)

* Hide SerializationContext from public API on TransactionBuilder

(cherry picked from commit 6ff7b7e)

* Hide SerializationContext from public API on TransactionBuilder

(cherry picked from commit 6ff7b7e)

* Address feedback on confidential identities docs (#1701)

* Address minor comments on confidential identities docs

* Expand on implementation details of confidential identities

* Cleanup

* Clarify details of the data blob in the swap identites flow

* Add that certificate path is not made public for confidential identities

* FlowSession docs (#1693)

* FlowSession docs (#1660)

* FlowSession docs

* PR comments

* Milder example flow name

* Fixes bugs with contract constraints (#1696)

* Added schedulable flows to cordapp scanning

Fixed a bug where the core flows are included in every cordapp. Added a test to prove the scheduled flows are loaded correctly. Added scheduled flow support to cordapp.

Renabled broken test.

Fixed test to prove cordapps aren't retreived from network.

Review fixes.

Fixed a test issue caused by gradle having slightly different paths to IntelliJ

* Fixed test for real this time.

* Consistent use of CordaException and CordaRuntimeException (#1710)

* Custom exceptions in corda, should either derive from an appropriate closely related java exception, or CordaException, or CordaRuntimeException. They should not inherit just from Exception, or RuntimeException.

Handle PR comments

Add nicer constructors to CordaException and CordaRuntimeException

* Fix ambiguous defaulted constructor

* Add @suppress (#1725)

* Git-ignore Node Explorer config. (#1709)

* add message warning windows users they might need to manually kill explorer demo nodes started by gradle (#1717) (#1726)

* Misc documentation fixes (#1694)

(cherry picked from commit 592896f)

* Document -parameters compiler arg for Java CorDapps. (#1712)

* Correct non-anonymous two party trade flow (#1731)

* Parameterize TwoPartyTradeFlowTests to confirm deanonymised functionality works.
* Correct handling of counterparty using well known identity in TWoPartyTradeFlow

* CORDA-594 - SIMM Demo doc update (#1723) (#1735)

* CORDA-594 - SIMM Demo doc update

For V1 write a series of JSON / curl commands a user can follow to run
the demo

* Review Comments

* Updated the rationale behind as to why SIMM was introduced.

* typo

* Cordapps now have a name field. (#1664)

Corrected cordapp name generation.

Added changelog entry.

* Small API fixes against M16 (#1737)

* Move CompositeSignaturesWithKeys into net.corda.core.crypto package.

(cherry picked from commit 8f29562)

* Rename and move CordaPluginRegistry to reflect its real purpose now.
Simplify serialization code a bit.

(cherry picked from commit e2ecd3a)

* Docs: docsite improvements

* Remove discussion of webserver from 'writing a cordapp' page.
* Fixup some flow docs.
* Add a couple more package descriptions.

(cherry picked from commit 2aedc43)

* Review comments

(cherry picked from commit ba1d007)

* Review comments - always apply default whitelist and no longer load it via ServiceLoader

(cherry picked from commit 7d4d7bb)

* Added wording about renaming services resource file

* Update corda version tag to 1.0.0-RC4 (#1734)

* Update corda version tag to 1.0.0-RC3

* Update corda version tag to 1.0.0-RC4

* Update build.gradle

* V1 tests and fixes for the ContractConstraints work (#1739)

* V1 tests and fixes for the ContractConstraints work

* More fixes.

* Added a contract constraints section to the key concepts doc. (#1704)

Documentation for contract constraints.

Added to index.

Review fixes round 1.

More review fixes.

Review fixes.

Explained package contents.

review fixes.

Addressed RGB's final review comments.

Updated source code type to 'java'

* Fixes dead links. (#1749)

* Update gradle plugins version to 1.0.0 (#1753)

* Update Readme (#1756)

* Update Readme

Minor tweaks to Readme -- consistent capitalisation and more descriptive list of features (also reordered to put the important things first)

* Copied master readme.

* Update Readme

Minor tweaks to Readme -- consistent capitalisation and more descriptive list of features (also reordered to put the important things first)

* Fixes .rst formatting. (#1751)

* Updates tutorials. (#1649)

* Updates tutorials.

* Addresses review comments.

* Tutorial refresh for v1.0 and moving of code into separate files. (#1758)

* Moves code sections in tutorials to code files.

* Removes wallet references.

* Updates repo layout doc.

* Removes remaining cordapp-tutorial references, replaced with cordapp-example.

* Fixes broken link.

* Misc docs fixes.

* Refreshes the ServiceHub and rpc ops api pages.

* Updates the cheat sheet.

* Updates cookbooks.

* Refreshes the running-a-notary tutorial.

* Updates flow-testing tutorial

* Updates tear-offs tutorial.

* Refreshes integration-testing tutorial.

* Updates to contract tutorial and accompanying code to bring inline with V1 release.

* Refreshes contract-upgrade tutorial.

* Fixed broken code sample in "writing a contract" and updated contracts dsl.

* Added contract ref to java code. Fixed broken rst markup.

* Updates transaction-building tutorial.

* Updates the client-rpc and flow-state-machines tutorials.

* Updates the oracles tutorial.

* Amended country in X500 names from "UK" to "GB"

* Update FlowCookbook.kt

* Amended cheatsheet. Minor update on contract upgrades tutoraial.

* Added `extraCordappPackagesToScan` to node driver.

* Changes to match new function signature.

* Update to reflect change in location of cash contract name.

* CORDA-670: Correct scanned packages in network visualiser (#1763)

* Add CorDapp dependency of IRS to network visualiser

* Set CorDapp directories

* Checking out the latest milestone will no longer be required. (#1761)

* Updated documentation indices (#1754)

* Update documentation indices.

* Reference a moveable tag for V1 docs.
Remove redundant warning text.

* Reverted proposed usage of new docs release tag

* Minor: print a deprecation warning when the web server starts. (#1767)

* Release and upgrade notes for V1.0 (#1736)

* Release and upgrade notes for V1.0

* Update changelog.rst

* Update changelog.rst

* Formatting.

* Incorporating review feedback from KB and MN.

* "guarantee" instead of "promise"

* Updated with final review comments from KB and RGB.

* Updated upgrade notes to describe migration from removed CordaPluginRegistry.

* Minor clarification.

* Minor updates following final RGB feedback.

* Kat's further pedantic feedback

* Minor changes following feedback from KB.

* Incorporating review feedback from MH.

* killed 'patent-pending'

* Made the visualiser into a regular JVM module - not a CorDapp. (#1771)

* Docs: more package descriptions and take non-stabilised APIs out of the docs build. (#1775)

* Update corda version tag to 1.0.0

* Updated release notes to fix minor typos (#1779)

Fixed bold type on simplified annotation driven scanning bullet and added bold type to module name bullets

* Fixed drop down.. probably. (#1780)

* fixed formatting for release notes. (#1782)

* Improve API page wording (#1784)

* Removed "unreleased" sections from the release notes and change log.

* Merge remote-tracking branch 'origin/release-V1' into colljos-merge-v1-docs

# Conflicts:
#	build.gradle
#	client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt
#	client/rpc/src/main/kotlin/net/corda/client/rpc/CordaRPCClient.kt
#	client/rpc/src/main/kotlin/net/corda/client/rpc/PermissionException.kt
#	constants.properties
#	core/src/main/kotlin/net/corda/core/flows/FlowSession.kt
#	core/src/test/kotlin/net/corda/core/contracts/DummyContractV2Tests.kt
#	core/src/test/kotlin/net/corda/core/flows/ContractUpgradeFlowTest.kt
#	docs/source/api-flows.rst
#	docs/source/api-index.rst
#	docs/source/changelog.rst
#	docs/source/example-code/src/main/java/net/corda/docs/java/tutorial/testdsl/CommercialPaperTest.java
#	docs/source/example-code/src/main/kotlin/net/corda/docs/FlowCookbook.kt
#	docs/source/example-code/src/main/kotlin/net/corda/docs/tutorial/contract/TutorialContract.kt
#	docs/source/example-code/src/main/kotlin/net/corda/docs/tutorial/testdsl/TutorialTestDSL.kt
#	docs/source/hello-world-state.rst
#	docs/source/key-concepts-contract-constraints.rst
#	docs/source/serialization.rst
#	docs/source/tut-two-party-flow.rst
#	docs/source/tutorial-tear-offs.rst
#	node-api/src/main/kotlin/net/corda/nodeapi/internal/serialization/CordaClassResolver.kt
#	node-api/src/test/java/net/corda/nodeapi/internal/serialization/ForbiddenLambdaSerializationTests.java
#	node-api/src/test/java/net/corda/nodeapi/internal/serialization/LambdaCheckpointSerializationTest.java
#	node/src/integration-test/kotlin/net/corda/node/services/AttachmentLoadingTests.kt
#	node/src/integration-test/kotlin/net/corda/services/messaging/MQSecurityTest.kt
#	node/src/main/kotlin/net/corda/node/internal/NodeStartup.kt
#	node/src/test/kotlin/net/corda/node/internal/cordapp/CordappLoaderTest.kt
#	node/src/test/kotlin/net/corda/node/services/NotaryChangeTests.kt
#	samples/attachment-demo/src/main/kotlin/net/corda/attachmentdemo/AttachmentDemo.kt
#	samples/trader-demo/src/main/kotlin/net/corda/traderdemo/TraderDemo.kt
#	testing/node-driver/src/integration-test/kotlin/net/corda/testing/FlowStackSnapshotTest.kt
#	testing/node-driver/src/main/kotlin/net/corda/testing/driver/Driver.kt
#	testing/node-driver/src/main/kotlin/net/corda/testing/node/MockNode.kt
#	webserver/src/main/kotlin/net/corda/webserver/internal/NodeWebServer.kt
2017-10-03 17:32:11 +01:00

22 KiB

Running the demos

The Corda repository contains a number of demo programs demonstrating Corda's functionality:

  1. The trader-demo, which shows a delivery-vs-payment atomic swap of commercial paper for cash
  2. The irs-demo, which shows two nodes establishing an interest rate swap and performing fixings with a rates oracle
  3. The attachment-demo, which demonstrates uploading attachments to nodes
  4. The notary-demo, which shows three different types of notaries and a single node getting multiple transactions notarised
  5. The bank-of-corda-demo, which shows a node acting as an issuer of assets (the Bank of Corda) while remote client applications request issuance of some cash on behalf of a node called Big Corporation

If any of the demos don't work, please raise an issue on GitHub.

Note

If you are running the demos from the command line in Linux (but not macOS), you may have to install xterm.

Note

If you would like to see flow activity on the nodes type in the node terminal flow watch.

Trader demo

This demo brings up four nodes: Bank A, Bank B, Bank Of Corda, and a notary/network map node that they all use. Bank A will be the buyer, and requests some cash from the Bank of Corda in order to acquire commercial paper from Bank B, the seller.

To run from the command line in Unix:

  1. Run ./gradlew samples:trader-demo:deployNodes to create a set of configs and installs under samples/trader-demo/build/nodes
  2. Run ./samples/trader-demo/build/nodes/runnodes to open up four new terminals with the four nodes
  3. Run ./gradlew samples:trader-demo:runBank to instruct the bank node to issue cash and commercial paper to the buyer and seller nodes respectively.
  4. Run ./gradlew samples:trader-demo:runSeller to trigger the transaction. If you entered flow watch

you can see flows running on both sides of transaction. Additionally you should see final trade information displayed to your terminal.

To run from the command line in Windows:

  1. Run gradlew samples:trader-demo:deployNodes to create a set of configs and installs under samples\trader-demo\build\nodes
  2. Run samples\trader-demo\build\nodes\runnodes to open up four new terminals with the four nodes
  3. Run gradlew samples:trader-demo:runBank to instruct the buyer node to request issuance of some cash from the Bank of Corda node
  4. Run gradlew samples:trader-demo:runSeller to trigger the transaction. If you entered flow watch

you can see flows running on both sides of transaction. Additionally you should see final trade information displayed to your terminal.

IRS demo

This demo brings up three nodes: Bank A, Bank B and a node that simultaneously runs a notary, a network map and an interest rates oracle. The two banks agree on an interest rate swap, and then do regular fixings of the deal as the time on a simulated clock passes.

To run from the command line in Unix:

  1. Run ./gradlew samples:irs-demo:deployNodes to install configs and a command line tool under samples/irs-demo/build
  2. Run ./gradlew samples:irs-demo:installDist
  3. Move to the samples/irs-demo/build directory
  4. Run ./nodes/runnodes to open up three new terminals with the three nodes (you may have to install xterm).

To run from the command line in Windows:

  1. Run gradlew.bat samples:irs-demo:deployNodes to install configs and a command line tool under samples\irs-demo\build
  2. Run gradlew.bat samples:irs-demo:installDist
  3. Run cd samples\irs-demo\build to change current working directory
  4. Run nodes\runnodes to open up several 6 terminals, 2 for each node. First terminal is a web-server associated with every node and second one is Corda interactive shell for the node.

This demo also has a web app. To use this, run nodes and then navigate to http://localhost:10007/web/irsdemo and http://localhost:10010/web/irsdemo to see each node's view of the ledger.

To use the web app, click the "Create Deal" button, fill in the form, then click the "Submit" button. You can then use the time controls at the top left of the home page to run the fixings. Click any individual trade in the blotter to view it.

Note

The IRS web UI currently has a bug when changing the clock time where it may show no numbers or apply fixings inconsistently. The issues will be addressed in a future milestone release. Meanwhile, you can take a look at a simpler oracle example https://github.com/corda/oracle-example

Attachment demo

This demo brings up three nodes, and sends a transaction containing an attachment from one to the other.

To run from the command line in Unix:

  1. Run ./gradlew samples:attachment-demo:deployNodes to create a set of configs and installs under samples/attachment-demo/build/nodes
  2. Run ./samples/attachment-demo/build/nodes/runnodes to open up three new terminal tabs/windows with the three nodes and webserver for BankB
  3. Run ./gradlew samples:attachment-demo:runRecipient, which will block waiting for a trade to start
  4. Run ./gradlew samples:attachment-demo:runSender in another terminal window to send the attachment. Now look at the other windows to see the output of the demo

To run from the command line in Windows:

  1. Run gradlew samples:attachment-demo:deployNodes to create a set of configs and installs under samples\attachment-demo\build\nodes
  2. Run samples\attachment-demo\build\nodes\runnodes to open up three new terminal tabs/windows with the three nodes and webserver for BankB
  3. Run gradlew samples:attachment-demo:runRecipient, which will block waiting for a trade to start
  4. Run gradlew samples:attachment-demo:runSender in another terminal window to send the attachment. Now look at the other windows to see the output of the demo

Notary demo

This demo shows a party getting transactions notarised by either a single-node or a distributed notary service. All versions of the demo start two counterparty nodes. One of the counterparties will generate transactions that transfer a self-issued asset to the other party and submit them for notarisation. The Raft version of the demo will start three distributed notary nodes. The BFT SMaRt version of the demo will start four distributed notary nodes.

The output will display a list of notarised transaction IDs and corresponding signer public keys. In the Raft distributed notary, every node in the cluster can service client requests, and one signature is sufficient to satisfy the notary composite key requirement. In the BFT SMaRt distributed notary, three signatures are required. You will notice that successive transactions get signed by different members of the cluster (usually allocated in a random order).

To run the Raft version of the demo from the command line in Unix:

  1. Run ./gradlew samples:notary-demo:deployNodes, which will create all three types of notaries' node directories with configs under samples/notary-demo/build/nodes/nodesRaft (nodesBFT and nodesSingle for BFT and Single notaries).
  2. Run ./samples/notary-demo/build/nodes/nodesRaft/runnodes, which will start the nodes in separate terminal windows/tabs. Wait until a "Node started up and registered in ..." message appears on each of the terminals
  3. Run ./gradlew samples:notary-demo:notarise to make a call to the "Party" node to initiate notarisation requests In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys

To run from the command line in Windows:

  1. Run gradlew samples:notary-demo:deployNodes, which will create all three types of notaries' node directories with configs under samples/notary-demo/build/nodes/nodesRaft (nodesBFT and nodesSingle for BFT and Single notaries).
  2. Run samples\notary-demo\build\nodes\nodesRaft\runnodes, which will start the nodes in separate terminal windows/tabs. Wait until a "Node started up and registered in ..." message appears on each of the terminals
  3. Run gradlew samples:notary-demo:notarise to make a call to the "Party" node to initiate notarisation requests In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys

To run the BFT SMaRt notary demo, use nodesBFT instead of nodesRaft in the path (you will see messages from notary nodes trying to communicate each other sometime with connection errors, that's normal). For a single notary node, use nodesSingle.

Distributed notary nodes store consumed states in a replicated commit log, which is backed by a H2 database on each node. You can ascertain that the commit log is synchronised across the cluster by accessing and comparing each of the nodes' backing stores by using the H2 web console:

  • Firstly, download H2 web console (download the "platform-independent zip"), and start it using a script in the extracted folder: sh h2/bin/h2.sh (or h2\bin\h2 for Windows)

  • If you are uncertain as to which version of h2 to install or if you have connectivity issues, refer to build.gradle located in the corda directory and locate h2_version. Use a client of the same major version - even if still in beta.

  • The H2 web console should start up in a web browser tab. To connect we first need to obtain a JDBC connection string. Each node outputs its connection string in the terminal window as it starts up. In a terminal window where a notary node is running, look for the following string:

    Database connection url is : jdbc:h2:tcp://10.18.0.150:56736/node

    You can use the string on the right to connect to the h2 database: just paste it into the JDBC URL field and click Connect. You will be presented with a web application that enumerates all the available tables and provides an interface for you to query them using SQL

  • The committed states are stored in the NOTARY_COMMITTED_STATES table (for Raft) or NODE_BFT_SMART_NOTARY_COMMITTED_STATES (for BFT). Note that in the Raft case the raw data is not human-readable, but we're only interested in the row count for this demo

Bank Of Corda demo

This demo brings up three nodes: a notary, a node acting as the Bank of Corda that accepts requests for issuance of some asset and a node acting as Big Corporation which requests issuance of an asset (cash in this example).

Upon receipt of a request the Bank of Corda node self-issues the asset and then transfers ownership to the requester after successful notarisation and recording of the issue transaction on the ledger.

Note

The Bank of Corda is somewhat like a "Bitcoin faucet" that dispenses free bitcoins to developers for testing and experimentation purposes.

To run from the command line in Unix:

  1. Run ./gradlew samples:bank-of-corda-demo:deployNodes to create a set of configs and installs under samples/bank-of-corda-demo/build/nodes
  2. Run ./samples/bank-of-corda-demo/build/nodes/runnodes to open up three new terminal tabs/windows with the three nodes
  3. Run ./gradlew samples:bank-of-corda-demo:runRPCCashIssue to trigger a cash issuance request
  4. Run ./gradlew samples:bank-of-corda-demo:runWebCashIssue to trigger another cash issuance request. Now look at your terminal tab/window to see the output of the demo

To run from the command line in Windows:

  1. Run gradlew samples:bank-of-corda-demo:deployNodes to create a set of configs and installs under samples\bank-of-corda-demo\build\nodes
  2. Run samples\bank-of-corda-demo\build\nodes\runnodes to open up three new terminal tabs/windows with the three nodes
  3. Run gradlew samples:bank-of-corda-demo:runRPCCashIssue to trigger a cash issuance request
  4. Run gradlew samples:bank-of-corda-demo:runWebCashIssue to trigger another cash issuance request. Now look at the your terminal tab/window to see the output of the demo

Note

To verify that the Bank of Corda node is alive and running, navigate to the following URL: http://localhost:10007/api/bank/date

In the window you run the command you should see (in case of Web, RPC is simmilar):

  • Requesting Cash via Web ...
  • Successfully processed Cash Issue request

If you want to see flow activity enter in node's shell flow watch. It will display all state machines running currently on the node.

Launch the Explorer application to visualize the issuance and transfer of cash for each node:

./gradlew tools:explorer:run (on Unix) or gradlew tools:explorer:run (on Windows)

Using the following login details:

  • For the Bank of Corda node: localhost / port 10006 / username bankUser / password test
  • For the Big Corporation node: localhost / port 10009 / username bigCorpUser / password test

See https://docs.corda.net/node-explorer.html for further details on usage.

SIMM and Portfolio Demo - aka the Initial Margin Agreement Demo

Background and SIMM Introduction

This app is a demonstration of how Corda can be used for the real world requirement of initial margin calculation and agreement; featuring the integration of complex and industry proven third party libraries into Corda nodes.

SIMM is an acronym for "Standard Initial Margin Model". It is effectively the calculation of a "margin" that is paid by one party to another when they agree a trade on certain types of transaction.

The SIMM was introduced to standardise the calculation of how much margin counterparties charge each other on their bilateral transactions. Before SIMM, each counterparty computed margins according to its own model and it was made it very difficult to agree the exact margin with the counterparty that faces the same trade on the other side.

To enact this, in September 2016, the ISDA committee - with full backing from various governing bodies -issued a ruling on what is known as the ISDA SIMM ™ model, a way of fairly and consistently calculating this margin. Any parties wishing to trade a financial product that is covered under this ruling would, independently, use this model and calculate their margin payment requirement, agree it with their trading counterparty and then pay (or receive, depending on the results of this calculation) this amount. In the case of disagreement that is not resolved in a timely fashion, this payment would increase and so therefore it is in the parties' interest to reach agreement in as short as time frame as possible.

To be more accurate, the SIMM calculation is not performed on just one trade - it is calculated on an aggregate of intermediary values (which in this model are sensitivities to risk factors) from a portfolio of trades; therefore the input to a SIMM is actually this data, not the individual trades themselves.

Also note that implementations of the SIMM are actually protected and subject to license restrictions by ISDA (this is due to the model itself being protected). We were fortunate enough to technically partner with OpenGamma who allowed us to demonstrate the SIMM process using their proprietary model. In the source code released, we have replaced their analytics engine with very simple stub functions that allow the process to run without actually calculating correct values, and can easily be swapped out in place for their real libraries.

What happens in the demo (notionally)

Preliminaries
  • Ensure that there are a number of live trades with another party based on financial products that are covered under the ISDA SIMM agreement (if none, then use the demo to enter some simple trades as described below).
Initial Margin Agreement Process
  • Agree that one will be performing the margining calculation against a portfolio of trades with another party, and agree the trades in that portfolio. In practice, one node will start the flow but it does not matter which node does.
  • Individually (at the node level), identify the data (static, reference etc) one will need in order to be able to calculate the metrics on those trades
  • Confirm with the other counterparty the dataset from the above set
  • Calculate any intermediary steps and values needed for the margin calculation (ie sensitivities to risk factors)
  • Agree on the results of these steps
  • Calculate the initial margin
  • Agree on the calculation of the above with the other party
  • In practice, pay (or receive) this margin (omitted for the sake of complexity for this example)

Demo execution (step by step)

Setting up the Corda infrastructure

To run from the command line in Unix:

  1. Deploy the nodes using ./gradlew samples:simm-valuation-demo:deployNodes
  2. Run the nodes using ./samples/simm-valuation-demo/build/nodes/runnodes

To run from the command line in Windows:

  1. Deploy the nodes using gradlew samples:simm-valuation-demo:deployNodes
  2. Run the nodes using samples\simm-valuation-demo\build\nodes\runnodes

Getting Bank A's details

From the command line run

curl http://localhost:10005/api/simmvaluationdemo/whoami

The response should be something like

{
    "self" : {
        "id" : "8Kqd4oWdx4KQGHGQW3FwXHQpjiv7cHaSsaAWMwRrK25bBJj792Z4rag7EtA",
        "text" : "C=GB,L=London,O=Bank A"
    },
    "counterparties" : [
        {
            "id" : "8Kqd4oWdx4KQGHGL1DzULumUmZyyokeSGJDY1n5M6neUfAj2sjbf65wYwQM",
            "text" : "C=JP,L=Tokyo,O=Bank C"
        },
        {
            "id" : "8Kqd4oWdx4KQGHGTBm34eCM2nrpcWKeM1ZG3DUYat3JTFUQTwB3Lv2WbPM8",
            "text" : "C=US,L=New York,O=Bank B"
        }
    ]
}

Now, if we ask the same question of Bank C we will see that it's id matches the id for Bank C as a counter party to Bank A and Bank A will appear as a counter party

curl -i -H "Content-Type: application/json" -X GET http://localhost:10011/api/simmvaluationdemo/whoami

Creating a trade with Bank C

In what follows, we assume we are Bank A (which is listening on port 10005)

Notice the id field in the output of the whoami command. We are going to use the id assocatied with Bank C, one of our counter parties, to create a trade. The general command for this is:

curl -i -H "Content-Type: application/json" -X PUT -d <<<JSON representation of the trade>>>  http://localhost:10005/api/simmvaluationdemo/<<<counter party id>>>/trades

where the representation of the trade is

{
    "id"          : "trade1",
    "description" : "desc",
    "tradeDate"   : [ 2016, 6, 6 ],
    "convention"  : "EUR_FIXED_1Y_EURIBOR_3M",
    "startDate"   : [ 2016, 6, 6 ],
    "endDate"     : [ 2020, 1, 2 ],
    "buySell"     : "BUY",
    "notional"    : "1000",
    "fixedRate"   : "0.1"
}

Continuing our example, the specific command we would run is

curl -i -H "Content-Type: application/json" \
    -X PUT \
    -d '{"id":"trade1","description" : "desc","tradeDate" : [ 2016, 6, 6 ],  "convention" : "EUR_FIXED_1Y_EURIBOR_3M",  "startDate" : [ 2016, 6, 6 ],  "endDate" : [ 2020, 1, 2 ],  "buySell" : "BUY",  "notional" : "1000",  "fixedRate" : "0.1"}' \
    http://localhost:10005/api/simmvaluationdemo/8Kqd4oWdx4KQGHGL1DzULumUmZyyokeSGJDY1n5M6neUfAj2sjbf65wYwQM/trades

With an expected response of

HTTP/1.1 202 Accepted
Date: Thu, 28 Sep 2017 17:19:39 GMT
Content-Type: text/plain
    Access-Control-Allow-Origin: *
Content-Length: 2
Server: Jetty(9.3.9.v20160517)

Verifying trade completion

With the trade completed and stored by both parties, the complete list of trades with our couterparty can be seen with the following command

curl -X GET http://localhost:10005/api/simmvaluationdemo/<<<counter party id>>>/trades

The command for our example, using Bank A, would thus be

curl -X GET http://localhost:10005/api/simmvaluationdemo/8Kqd4oWdx4KQGHGL1DzULumUmZyyokeSGJDY1n5M6neUfAj2sjbf65wYwQM/trades

whilst a specific trade can be seen with

curl  -X GET http://localhost:10005/api/simmvaluationdemo/<<<counter party id>>>/trades/<<<trade id>>>

If we look at the trade we created above, we assigned it the id "trade1", the complete command in this case would be

curl  -X GET http://localhost:10005/api/simmvaluationdemo/8Kqd4oWdx4KQGHGL1DzULumUmZyyokeSGJDY1n5M6neUfAj2sjbf65wYwQM/trades/trade1

Generating a valuation

curl -i -H "Content-Type: application/json" \
    -X POST \
    -d <<<JSON representation>>>
    http://localhost:10005/api/simmvaluationdemo/<<<counter party id>>>/portfolio/valuations/calculate

Again, the specific command to continue our example would be

curl -i -H "Content-Type: application/json" \
    -X POST \
    -d '{"valuationDate":[2016,6,6]}' \
    http://localhost:10005/api/simmvaluationdemo/8Kqd4oWdx4KQGHGL1DzLumUmZyyokeSGJDY1n5M6neUfAj2sjbf65wYwQM/portfolio/valuations/calculate

Viewing a valuation

In the same way we can ask for specific instances of trades with a counter party, we can request details of valuations

curl -i -H "Content-Type: application/json" -X GET http://localhost:10005/api/simmvaluationdemo/<<<counter party id>>>/portfolio/valuations

The specific command for out Bank A example is

curl -i -H "Content-Type: application/json" \
  -X GET http://localhost:10005/api/simmvaluationdemo/8Kqd4oWdx4KQGHGL1DzULumUmZyyokeSGJDY1n5M6neUfAj2sjbf65YwQM/portfolio/valuations