HW16 Composer: Tea trade

Create a Business Network Archive (BNA) with the appropriate models, transactions, and access constraints that fulfill the requirements below. The BNA must have an initial transaction (setupHomework) that sets up a ledger state, where the fulfillment of each requirement can be demonstrated (assuming that the ledger is empty before the call of the initial transaction). Transactions that would dynamically add participants or assets are not needed, unless noted explicitly under the requirements, except the initializer transaction.

Please test your solution on Composer Playground before submission.

For every Participant and Asset type, the unique identifier must be a non-optional String field with the name id. The value of the field must conform to the following format: <TYPENAME>_<COUNTER>. For example, if we have a Participant type named User, then the id of the first created user must be USER_0, the id of the second user must be USER_1, etc.

Problem statement

Implement a BNA for tea sales.

• There are two participant types: Supplier and Consumer.
• Suppliers have names (non-unique), a list of tea containers, a sale price, and account balances.
• Consumers have names (non-unique), account balances, and a list of tea containers.
• Suppliers can:
  • produce tea, creating a new container of tea and adding it to their list.
  • set their selling price.
• Consumers can:
  • buy a single tea container at a time, by specifying only the supplier, which transfers the appropriate funds to the supplier's account while moving the item from their list to the consumers.
  • drink tea, deleting the tea container.
• If the consumer specified a supplier with no tea containers, the buy transaction fails.

Additional requirements:

• The initializer transaction should set up at least one supplier, one consumer, and one tea container for each participant.
• Tea containers must be separate assets, not just list entries.
• Transactions that create suppliers or consumers are not required.
• Negative balances are not possible, transactions that'd create such a state should be rejected.

Example scenario

Alice is a tea producer with an account balance of 0 units. Bob is a consumer with 10 units. Alice produces a container of tea and sets the selling price at 2 units. Bob buys from Alice, transferring 2 units to her account, then drinks the tea.

Transactions

• createTea
• setSellPrice
• buyTea
• drinkTea