Hyperledger Blockchain Day 9: Giới thiệu về Model File (file .cto)
Hyperledger Blockchain Day 9: Giới thiệu về Model File (file .cto)
Model file dùng để xác định các thành phần tham gia vào network như các tổ chức, công ty, loại hàng hóa,... Đây như kiểu một file Schema khai báo dữ liệu trong backend.
Một Hyperledger CTO file sẽ có các thành phần chính sau:
- Namespace: Đại diện cho toàn bộ các thành phần trong một file cto (dùng khi được thực thi trong các action khác).
- Hệ thống các định nghĩa về các thành phần, đối tượng tham gia (participants), các asset (tài sản), các transactions (giao dịch), các hành động thực thi (events).
- Các thành khác được import từ một file khác vào.
Trên composer playground như đã thiết lập ở bài trước, model được thiết lập trong Model File và có đuôi .cto; chúng ta có thể import Model File từ máy tính, hoặc chỉnh sửa luôn trên playground để test kết quả.
Một số thành phần và trình tự thiết lập Model File:
1. Đặt tên cho namespace: Ví dụ: namespace org.acme.shipping.perishable
Org: đại diện cho organization - tổ chức - ở đây có tên acme.shipping; phần tên cuối cùng thường xác định nội dung model; ở đây perishable là dễ hỏng, chúng ta đang đi xây dựng một Blockchain để tracking theo dõi chất lượng các loại sản phẩm nông sản.
2. Định nghĩa các thành phần, đối tượng tham gia (resources defination): Các thành phần tham gia thường được định nghĩa theo các Class; ví dụ (assets, participant, transactions...).
Xác định các chủ thể tham gia network:
Chủ thể tham gia được định nghĩa bởi từ khóa "participant" tiếp đó đến tên chủ thể "Bussiness"; "identified by email" thể hiện đối tượng này sẽ được nhận dạng bởi email (như kiểu mã ID).
Bên trong class ta có các biến "email, address, accountBalance" được xác định bởi các kiểu dữ liệu của nó như "String, Address, Double" trong đó String và Double là mặc định, Address là một concepts sẽ do chúng ta tạo ra.
Address là một thành phần trong Class nhưng, Address sẽ có một số thông tin thêm như: country, city, street, zipcode; dó đó ta không thể định nghĩa trực tiếp biến address trong Class mà phải sử dụng đến Concept (định nghĩa)
concept Address {
o String city optional
o String country
o String street optional
o String zip optional
}
Như vậy các biến city, country, street, zip đã được đưa vào cho đối tượng Bussiness; optional ở đây là một thuộc tính thể hiện biến đó có thể nhập hoặc không.
abstract - thể hiện participant này sẽ không hiển thị trên playground.
Tạo 3 đối tượng Grower, Importer, và Shipper tham gia vào network.
participant Grower extends Business {
}
participant Shipper extends Business {
}
participant Importer extends Business {
}
3 đối tượng này sẽ hiện thị trên playground vì không set thuộc tính abstract.
Ta thấy cả 3 đối tượng đều extends từ Bussiness, có nghĩa là chúng sẽ thừa hưởng đầy đủ thuộc tính từ Bussiness.
3. Tạo Asset Contract.
asset Contract identified by contractId {
o String contractId
--> Grower grower
--> Shipper shipper
--> Importer importer
o DateTime arrivalDateTime
o Double unitPrice
o Double minTemperature
o Double maxTemperature
o Double minPenaltyFactor
o Double maxPenaltyFactor
}
asset cũng là từ khóa để tạo một class trong model, asset sẽ tạo ra một hợp đồng giữa ba bên đã đề cập ở trên. asset Contract này được đại diện bằng contractId để phân biệt các Contract với nhau.
Tiếp theo ta thiết lập các biến đối tượng grower, shipper, importer tham gia Contract, các biến này sẽ thuộc các participants Grower, Shipper, Importer ta vừa khai báo ở trên. "-->" để thể hiện mối quan hệ giữa biến đối tượng và đối tượng.
Như vậy các thông tin của grower, shipper, importer sẽ hiện trong Asset/Contract trên Playground. Bên cạnh đó một số thông tin về arrivalDatetime, unitPrice, minTemperature...cũng sẽ xuất hiện do chúng cũng được khai báo trong asset Contract.
Tương tự, ta tạo thêm một asset nữa đó là shipment, thể hiện việc giao nhận hàng hóa giữa 3 bên.
asset Shipment identified by shipmentId {
o String shipmentId
o ProductType type
o ShipmentStatus status
o Long unitCount
o TemperatureReading[] temperatureReadings optional
--> Contract contract
}
Ở đây shipment được phân biệt bởi biến shipmentId; biến thứ 2 type thể hiện loại sản phẩm. Loại sản phẩm này có thể là một số sản phẩm như: Chuối, táo, đào... Do đó để đưa nó vào asset tương tự concept ở trên, ta sử dụng một class với enum:
enum ProductType {
o BANANAS
o APPLES
o PEARS
o PEACHES
o COFFEE
}
Như vậy đối với participant ta dùng concept còn đối voiws asset ta dùng enum nếu muốn theme một biến có nhiều giá trị.
Biến thứ 3 là status để thể hiện tình trạng vận chuyển hàng hóa, được định nghĩa bởi kiểu dữ liệu ShipmentStatus, tương tự cũng là một enum như sau:
enum ShipmentStatus {
o CREATED
o IN_TRANSIT
o ARRIVED
}
Như vậy có 3 tình trạng vận chuyển của hàng hóa đó là: tạo đơn, đang vận chuyển và đã đến nơi.
Biến thứ 4 về số lượng sản phẩm unitcount có kiểu dữ liệu Long.
Biến thứ 5 về việc cập nhật nhiệt độ hàng hóa, để kiểm tra tình trạng hàng khi vận chuyển. Đây có dữ liệu kiểu mảng để cập nhật theo từng lần. Đây sẽ là điều kiện được xem xét khi thực thi transaction.
--> Contract contract: thể hiện shipment này sẽ thuộc contract nào vì ta có thể có nhiều shipment trong một contract hoặc ngược lại một shipment có thể thuộc nhiều contract.
Model file dùng để xác định các thành phần tham gia vào network như các tổ chức, công ty, loại hàng hóa,... Đây như kiểu một file Schema khai báo dữ liệu trong backend.
Một Hyperledger CTO file sẽ có các thành phần chính sau:
- Namespace: Đại diện cho toàn bộ các thành phần trong một file cto (dùng khi được thực thi trong các action khác).
- Hệ thống các định nghĩa về các thành phần, đối tượng tham gia (participants), các asset (tài sản), các transactions (giao dịch), các hành động thực thi (events).
- Các thành khác được import từ một file khác vào.
Trên composer playground như đã thiết lập ở bài trước, model được thiết lập trong Model File và có đuôi .cto; chúng ta có thể import Model File từ máy tính, hoặc chỉnh sửa luôn trên playground để test kết quả.
Một số thành phần và trình tự thiết lập Model File:
1. Đặt tên cho namespace: Ví dụ: namespace org.acme.shipping.perishable
Org: đại diện cho organization - tổ chức - ở đây có tên acme.shipping; phần tên cuối cùng thường xác định nội dung model; ở đây perishable là dễ hỏng, chúng ta đang đi xây dựng một Blockchain để tracking theo dõi chất lượng các loại sản phẩm nông sản.
2. Định nghĩa các thành phần, đối tượng tham gia (resources defination): Các thành phần tham gia thường được định nghĩa theo các Class; ví dụ (assets, participant, transactions...).
Xác định các chủ thể tham gia network:
abstract participant Business identified by email {
o String email
o Address address
o Double accountBalance
}
Chủ thể tham gia được định nghĩa bởi từ khóa "participant" tiếp đó đến tên chủ thể "Bussiness"; "identified by email" thể hiện đối tượng này sẽ được nhận dạng bởi email (như kiểu mã ID).
Bên trong class ta có các biến "email, address, accountBalance" được xác định bởi các kiểu dữ liệu của nó như "String, Address, Double" trong đó String và Double là mặc định, Address là một concepts sẽ do chúng ta tạo ra.
Address là một thành phần trong Class nhưng, Address sẽ có một số thông tin thêm như: country, city, street, zipcode; dó đó ta không thể định nghĩa trực tiếp biến address trong Class mà phải sử dụng đến Concept (định nghĩa)
concept Address {
o String city optional
o String country
o String street optional
o String zip optional
}
Như vậy các biến city, country, street, zip đã được đưa vào cho đối tượng Bussiness; optional ở đây là một thuộc tính thể hiện biến đó có thể nhập hoặc không.
abstract - thể hiện participant này sẽ không hiển thị trên playground.
Tạo 3 đối tượng Grower, Importer, và Shipper tham gia vào network.
participant Grower extends Business {
}
participant Shipper extends Business {
}
participant Importer extends Business {
}
3 đối tượng này sẽ hiện thị trên playground vì không set thuộc tính abstract.
Ta thấy cả 3 đối tượng đều extends từ Bussiness, có nghĩa là chúng sẽ thừa hưởng đầy đủ thuộc tính từ Bussiness.
3. Tạo Asset Contract.
asset Contract identified by contractId {
o String contractId
--> Grower grower
--> Shipper shipper
--> Importer importer
o DateTime arrivalDateTime
o Double unitPrice
o Double minTemperature
o Double maxTemperature
o Double minPenaltyFactor
o Double maxPenaltyFactor
}
asset cũng là từ khóa để tạo một class trong model, asset sẽ tạo ra một hợp đồng giữa ba bên đã đề cập ở trên. asset Contract này được đại diện bằng contractId để phân biệt các Contract với nhau.
Tiếp theo ta thiết lập các biến đối tượng grower, shipper, importer tham gia Contract, các biến này sẽ thuộc các participants Grower, Shipper, Importer ta vừa khai báo ở trên. "-->" để thể hiện mối quan hệ giữa biến đối tượng và đối tượng.
Như vậy các thông tin của grower, shipper, importer sẽ hiện trong Asset/Contract trên Playground. Bên cạnh đó một số thông tin về arrivalDatetime, unitPrice, minTemperature...cũng sẽ xuất hiện do chúng cũng được khai báo trong asset Contract.
Tương tự, ta tạo thêm một asset nữa đó là shipment, thể hiện việc giao nhận hàng hóa giữa 3 bên.
asset Shipment identified by shipmentId {
o String shipmentId
o ProductType type
o ShipmentStatus status
o Long unitCount
o TemperatureReading[] temperatureReadings optional
--> Contract contract
}
Ở đây shipment được phân biệt bởi biến shipmentId; biến thứ 2 type thể hiện loại sản phẩm. Loại sản phẩm này có thể là một số sản phẩm như: Chuối, táo, đào... Do đó để đưa nó vào asset tương tự concept ở trên, ta sử dụng một class với enum:
enum ProductType {
o BANANAS
o APPLES
o PEARS
o PEACHES
o COFFEE
}
Như vậy đối với participant ta dùng concept còn đối voiws asset ta dùng enum nếu muốn theme một biến có nhiều giá trị.
Biến thứ 3 là status để thể hiện tình trạng vận chuyển hàng hóa, được định nghĩa bởi kiểu dữ liệu ShipmentStatus, tương tự cũng là một enum như sau:
enum ShipmentStatus {
o CREATED
o IN_TRANSIT
o ARRIVED
}
Như vậy có 3 tình trạng vận chuyển của hàng hóa đó là: tạo đơn, đang vận chuyển và đã đến nơi.
Biến thứ 4 về số lượng sản phẩm unitcount có kiểu dữ liệu Long.
Biến thứ 5 về việc cập nhật nhiệt độ hàng hóa, để kiểm tra tình trạng hàng khi vận chuyển. Đây có dữ liệu kiểu mảng để cập nhật theo từng lần. Đây sẽ là điều kiện được xem xét khi thực thi transaction.
--> Contract contract: thể hiện shipment này sẽ thuộc contract nào vì ta có thể có nhiều shipment trong một contract hoặc ngược lại một shipment có thể thuộc nhiều contract.
Nhận xét
Đăng nhận xét