Disaster Recovery Support for Tokenization

You can configure Oracle Blockchain Platform for disaster recovery support in tokenization scenarios.

Before you can set up disaster recovery support in a tokenization scenario, the blockchain network must be configured for disaster recovery, using the following guidelines. For more information, see Add Oracle Blockchain Platform Participant Organizations to the Network.

In addition to the founder instance of Oracle Blockchain Platform, create at least two more participant instances and join them to the blockchain network.
Add at least two orderers from each participant instance to the blockchain network. Typically you add at least three orderers from each participant instance.
Join the participant organizations to the same channels and install chaincodes on the participant instances.
Ensure that the orderers from the participant instances are joined to the channels on the founder instance.

You can then prepare for disaster recovery in a tokenization scenario by designating a second instance of Oracle Blockchain Platform as a disaster recovery organization. When a primary Oracle Blockchain Platform instance is down and unable to send transactions to the chaincode, a secondary Oracle Blockchain Platform instance set up as a disaster recovery organization can be used to send the transaction to the chaincode on behalf of the primary instance.

In the following example, the founder organization on the primary instance is Org1MSP and the participant organization on the disaster recovery instance is Org2MSP.

To set up a second instance for disaster recovery in tokenization scenarios, complete the following steps.

Create custom enrollments on the disaster recovery organization and add a custom attribute for primaryOrgMSPId that is the ID of the founder organization (Org1MSP). You can use a tool such as Postman to create the custom enrollment. This enrollment indicates that Org2MSP is a disaster recovery organization for the primary organization, Org1MSP.
The following example shows an example request body for the REST endpoint {{bc-url}}/console/admin/api/v2/nodes/restproxies/{{bc-restproxy-id}}/enrollments. You can get the bc-restproxy-id value in the response from a GET request for the REST endpoint {{bc-url}}/console/admin/api/v2/nodes.
```
{
   "enrollmentId": "<enrollmentId>",
    "attributes":{
        "primaryOrgMSPId": "<primaryOrgId>"
    }
 }
```
The following example is the expected response.
```
{
"respMesg": "SUCCESS"
}
```
Add users to the custom enrollment. You can use Postman or the Oracle Blockchain Platform console to add users. The enrollment IDs and user names in the disaster recovery organization (Org2MSP) must match the enrollment IDs and user names in the primary organization (Org1MSP). The only difference is the custom attribute, primaryOrgMSPId, which points to the primary organization (Org1MSP).
The following example shows an example request body for the REST endpoint {{bc-url}}/console/admin/api/v2/nodes/restproxies/{{bc-restproxy-id}}/enrollments/{{bc-enrolment-id}}/users.
```
{
    "userName": "<userId>"
 }
```
The following example is the expected response.
```
{
"respMesg": "SUCCESS"
}
```