Removed flow-library doc page as it's redundant (#3307)

docs/source/api-flows.rst

@@ -602,7 +602,7 @@ transaction ourselves, we can automatically gather the signatures of the other r
         :dedent: 12
 
 Each required signer will need to respond by invoking its own ``SignTransactionFlow`` subclass to check the
-transaction and provide their signature if they are satisfied:
+transaction (by implementing the ``checkTransaction`` method) and provide their signature if they are satisfied:
 
 .. container:: codeset
 
@@ -618,6 +618,14 @@ transaction and provide their signature if they are satisfied:
         :end-before: DOCEND 16
         :dedent: 12
 
+Types of things to check include:
+
+    * Ensuring that the transaction received is the expected type, i.e. has the expected type of inputs and outputs
+    * Checking that the properties of the outputs are expected, this is in the absence of integrating reference
+      data sources to facilitate this
+    * Checking that the transaction is not incorrectly spending (perhaps maliciously) asset states, as potentially
+      the transaction creator has access to some of signer's state references
+
 SendTransactionFlow/ReceiveTransactionFlow
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Verifying a transaction received from a counterparty also requires verification of every transaction in its

docs/source/component-library-index.rst

@@ -4,7 +4,6 @@ Component library
 .. toctree::
    :maxdepth: 1
 
-   flow-library
    contract-catalogue
    financial-model
    contract-irs

docs/source/flow-library.rst

@@ -1,61 +0,0 @@
-Flow library
-============
-
-There are a number of built-in flows supplied with Corda, which cover some core functionality.
-
-FinalityFlow
-------------
-
-The ``FinalityFlow`` verifies the given transactions, then sends them to the specified notary.
-
-If the notary agrees that the transactions are acceptable then they are from that point onwards committed to the ledger,
-and will be written through to the vault. Additionally they will be distributed to the parties reflected in the participants
-list of the states.
-
-The transactions will be topologically sorted before commitment to ensure that dependencies are committed before
-dependers, so you don't need to do this yourself.
-
-The transactions are expected to have already been resolved: if their dependencies are not available in local storage or
-within the given set, verification will fail. They must have signatures from all necessary parties other than the notary.
-
-If specified, the extra recipients are sent all the given transactions. The base set of parties to inform of each
-transaction are calculated on a per transaction basis from the contract-given set of participants.
-
-The flow returns the same transactions, in the same order, with the additional signatures.
-
-
-CollectSignaturesFlow
----------------------
-
-The ``CollectSignaturesFlow`` is used to automate the collection of signatures from the counterparties to a transaction.
-
-You use the ``CollectSignaturesFlow`` by passing it a ``SignedTransaction`` which has at least been signed by yourself.
-The flow will handle the resolution of the counterparty identities and request a signature from each counterparty.
-
-Finally, the flow will verify all the signatures  and return a ``SignedTransaction`` with all the collected signatures.
-
-When using this flow on the responding side you will have to subclass the ``AbstractCollectSignaturesFlowResponder`` and
-provide your own implementation of the ``checkTransaction`` method. This is to add additional verification logic on the
-responder side. Types of things you will need to check include:
-
-* Ensuring that the transaction you are receiving is the transaction you *EXPECT* to receive. I.e. is has the expected
-  type of inputs and outputs
-* Checking that the properties of the outputs are as you would expect, this is in the absence of integrating reference
-  data sources to facilitate this for us
-* Checking that the transaction is not incorrectly spending (perhaps maliciously) one of your asset states, as potentially
-  the transaction creator has access to some of your state references
-
-Typically after calling the ``CollectSignaturesFlow`` you then called the ``FinalityFlow``.
-
-SendTransactionFlow/ReceiveTransactionFlow
-------------------------------------------
-
-The ``SendTransactionFlow`` and ``ReceiveTransactionFlow`` are used to automate the verification of the transaction by
-recursively checking the validity of all the dependencies. Once a transaction is received and checked it's inserted into
-local storage so it can be relayed and won't be checked again.
-
-The ``SendTransactionFlow`` sends the transaction to the counterparty and listen for data request as the counterparty
-validating the transaction, extra checks can be implemented to restrict data access by overriding the ``verifyDataRequest``
-method inside ``SendTransactionFlow``.
-
-The ``ReceiveTransactionFlow`` returns a verified ``SignedTransaction``.

docs/source/key-concepts-flows.rst

@@ -76,7 +76,7 @@ logic behind common processes such as:
 * Gathering signatures from counterparty nodes
 * Verifying a chain of transactions
 
-Further information on the available built-in flows can be found in :doc:`flow-library`.
+Further information on the available built-in flows can be found in :doc:`api-flows`.
 
 Concurrency
 -----------