Designing business models

Now that we have reviewed the basic composer model language and structure, it is time to implement an insurance claim using Hyperledger Composer.

For simplicity's sake, we will allow participants to have permission to read and write for all resources in this example. Remove the sample resource related to ACL and update the rule as follows:

rule EverybodyCanReadEverything {
description: "Allow all participants read access to all resources"
participant: "**"
operation: READ
resource: "com.packt.quickstart.claim.*"
action: ALLOW
}
rule EverybodyCanSubmitTransactions {
description: "Allow all participants to submit transactions"
participant: "**"
operation: CREATE
resource: "**"
action: ALLOW
}

With simplified ACL, we start to work on our model file as follows:

  1. Rename sample.cto as insurance-claim.cto
  2. Change namespace to com.packt.quickstart.claim and remove the remaining code
  3. Define the participants and assets

We wrote a chaincode called claimcontract.go in Chapter 16Exploring an Enterprise Blockchain Application using Hyperledger Fabric, that defines a struct for insuree, broker insurer, and claim. We can define participants and assets similar to this struct. It is quite straightforward, as follows:

      namespace com.packt.quickstart.claim
participant Insuree identified by id {
o String id
o String firstName
o String lastName
o String ssn
o String policyNumber
}
participant Company identified by id {
o String id
o String type
o String name
}
asset Claim identified by id {
o String id
o String desc
o Integer status
o String insureeId
o String brokerId
o String insurerId
o String comment
o String processAt
}
  1. Define the transactions and events. By using the Init function, we onboard insuree, as follows:
      transaction Init {
o String insureeId
o String firstName
o String lastName
o String ssn
o String policyNumber
}
event InitEvent {
--> Insuree insuree
}
  1. Composer's JavaScript API provides CRUD to create resources, including the participant. For the insurer and broker, we will use this approach. We will explain this in more detail when we do testing.
  2. Define ReportLost: An insuree reports a claim to a broker—this starts a claim, as follows:
      transaction ReportLost {
o String claimId
o String desc
o String insureeId
o String brokerId
}
event ReportLostEvent {
--> Claim claim
}
  1. Define RequestedInfo: A broker provides the requested information, as follows:
      transaction RequestedInfo {
--> Claim claim
}
event RequestedInfoEvent {
--> Claim claim
}
  1. Define SubmitClaim: A broker submits a claim to an issuer.
  2. Define ConfirmClaimSubmission: An issuer confirms the claim.
  3. Define ApproveClaim: An issuer process and approves the claim.

Step 8, 9, and 10 are transaction functions, and are very similar to step 7.

We have defined all of our transactions, participants, and assets in the model file. As a next step, we will implement the transaction we defined in the model file.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
52.15.38.176