Creating Your Uni
A Uni is comprised of multiple nodes that share a common data model. There is a separate page outlining how to model your data. On this page, we will address how to define and associate partners with the model and, ultimately, how to create the resources required of a Uni.
Registration File
The registration file is a JSON file used to define where to locate the schema and the nodes that are participating in a Uni. Optionally, the registration file can specify the location of an initial state file that is used to populate a newly created Uni with data.
Uni creators can either specify an initial static list of multiple nodes (ie static registration) or they can define a single node and invite additional users to create a node at a later point in time (ie dynamic registration).
Static Registration
If Uni creators know the parties that will comprise a Uni, they can statically define them in the registration file.
Sample static registration file
Note: This example uses a 3-node Uni configuration, which is not viable for Starter tier users given the node limits enforced. See full details on the Pricing page. Starter tier users can still follow this example by omitting one of the nodes in the configuration shown below.
Node CSP (cloud service provider): Valid values for this field are aws and azure
{
"name": "test-inventory",
"schema": "schema.json",
"initState": "initial-state.json",
"nodes": [
{
"name": "DistributionCenter",
"userId": "user1@domain1.com",
"region": "us-east-2",
"csp": "aws"
},
{
"name": "Retailer1",
"userId": "user2@domain2.com",
"region": "us-west-2",
"csp": "aws"
},
{
"name": "Retailer2",
"userId": "user3@domain3.com",
"region": "us-west-2",
"csp": "aws"
}
]
}
Each participant in the Uni will need to go through the registration process with the exact same schema and, if applicable, initState. The Uni will not be in a RUNNING state until all parties have gone through the registration process.
Dynamic Registration
If Uni creators are not sure of the parties in advance they can create a single node and add other users at a later point.
Sample dynamic registration file
{
"name": "test-inventory",
"schema": "schema.json",
"initState": "initial-state.json",
"nodes": [
{
"name": "DistributionCenter",
"userId": "user1@domain1.com",
"region": "us-east-2",
"csp": "aws"
}
]
}
In the sample file, there is only a single node - DistributionCenter. To add additional nodes, the Vendia Share manager of the DistributionCenter must invite additional parties. The invitation can be created from the Vendia Share CLI (share uni invite) or through the Vendia Share web application.
Once the initial Uni is created, it will be in a RUNNING state. Each participant can be added when the time is appropriate. There is no need for other parties to specify a schema or initial state. New nodes will have their data populated from the existing Uni.
When the new participant accepts the invitation and joins the Uni, the Uni will pause write operations as initial data is populated in the new node. Once the new node is up and running and data is in sync, the Uni will automatically return to the RUNNING state. Pending writes will be applied. Read requests to a Uni node are unaffected and will continue to work as expected while the new node is added to the Uni.
Adding a node
When a node is added to your uni, the new node's ledger and world state is seeded from a single node in the Uni. This node is called the Seed Node. The Seed Node is always the first node in the uni.
NOTE: Vendia Share users inviting new nodes to a Uni must have sufficient privileges. Vendia Share users accepting an invitation must also have sufficient privileges to join a Uni. Please review Vendia's Role-based Access Control documentation for more detail.
ANOTHER NOTE: Though many invitations can be out to new Uni participants, only one node can be added at a time.
Next Steps
Integrating a Vendia chain with other Cloud, Web, and Mobile Services