Hyperledger Composer创建业务参与者报错及企业员工授权操作问题

Got it, let's break this down step by step. First, that error you're hitting is because composer.business.Manager is an abstract type in Hyperledger Composer—you can't create instances of it directly. You need to define concrete subclasses for each of your business roles (Regulator, Manufacturer, etc.) that extend this abstract Manager class. Then we'll set up the links between employees like John and these businesses so they can act on their behalf.

Step 1: Fix the Abstract Type Error #

In your CTO model file, define concrete Manager subclasses for each of your business participant types. This gives Composer a tangible type to instantiate instead of the abstract base class. Here's an example:

namespace org.yourbiz.network

// Abstract base manager (extends the Composer core abstract Manager)
abstract participant BusinessManager extends composer.business.Manager {
  o String employeeId
}

// Concrete manager roles for each business type
participant RegulatorManager extends BusinessManager {
}

participant ManufacturerManager extends BusinessManager {
}

participant ScrapMerchantManager extends BusinessManager {
}

participant CompanyManager extends BusinessManager {
}

participant AuctionHouseManager extends BusinessManager {
}

Now you won't get that "no concrete extending type" error anymore—each business role has a valid, instantiable Manager subclass to use.

Step 2: Model Employees, Businesses, and Their Relationships #

Next, we need to model the actual business entities (like Regulator, Manufacturer) and the employees that manage them. Add these to your CTO file:

// Employee participant (people who work for businesses)
participant Employee identified by employeeId {
  o String employeeId
  o String fullName
  // Link the employee to their assigned manager role
  --> BusinessManager assignedRole
}

// Business entities (the actual companies/organizations)
participant Regulator identified by regulatorId {
  o String regulatorId
  o String organizationName
  // List of authorized managers for this regulator
  --> BusinessManager[] authorizedManagers
}

participant Manufacturer identified by manufacturerId {
  o String manufacturerId
  o String organizationName
  --> BusinessManager[] authorizedManagers
}

// Repeat similar definitions for ScrapMerchant, Company, AuctionHouse

This setup lets you:

• Create an Employee (John)
• Assign John a RegulatorManager or ManufacturerManager role
• Link that manager role to the corresponding business entity (e.g., add John's RegulatorManager to the Regulator's authorizedManagers list)

Step 3: Control Access with ACL Rules #

To ensure only authorized employees can act on behalf of a business, use Hyperledger Composer's ACL (Access Control List) rules. Add these to your .acl file:

// Allow RegulatorManagers to perform actions on their linked Regulator
rule RegulatorManagersCanActOnRegulator {
  description: "Authorized Regulator managers can interact with their regulator's resources"
  participant(p): "org.yourbiz.network.RegulatorManager"
  operation: ALL
  resource(r): "org.yourbiz.network.Regulator"
  condition: (r.authorizedManagers.indexOf(p) !== -1)
  action: ALLOW
}

// Allow ManufacturerManagers to act on their linked Manufacturer
rule ManufacturerManagersCanActOnManufacturer {
  description: "Authorized Manufacturer managers can interact with their manufacturer's resources"
  participant(p): "org.yourbiz.network.ManufacturerManager"
  operation: ALL
  resource(r): "org.yourbiz.network.Manufacturer"
  condition: (r.authorizedManagers.indexOf(p) !== -1)
  action: ALLOW
}

// Add similar rules for other business-manager pairs

These rules ensure that only managers listed in a business's authorizedManagers can perform operations on that business's resources.

Step 4: Implement Transaction Logic (Optional) #

If your transactions need explicit authorization checks, add validation in your transaction processor script. For example, for a SubmitRegulatoryAudit transaction:

/**
 * Submit a regulatory audit on behalf of a regulator
 * @param {org.yourbiz.network.SubmitRegulatoryAudit} tx
 * @transaction
 */
async function submitRegulatoryAudit(tx) {
  // Verify the submitter's assigned role is in the regulator's authorized managers
  const isAuthorized = tx.targetRegulator.authorizedManagers.some(manager => manager.getIdentifier() === tx.submittedBy.assignedRole.getIdentifier());
  
  if (!isAuthorized) {
    throw new Error(`${tx.submittedBy.fullName} is not authorized to act on behalf of ${tx.targetRegulator.organizationName}`);
  }

  // Proceed with transaction logic (e.g., save audit record to the ledger)
}

And the corresponding transaction definition in your CTO:

transaction SubmitRegulatoryAudit {
  o String auditDetails
  --> Regulator targetRegulator
  --> Employee submittedBy
}

Example Workflow to Test This Setup #

1. Create the business entity: Register a Regulator with ID REG-001 and name "National Environmental Agency".
2. Create the employee: Register John with employee ID EMP-001 and full name "John Doe".
3. Assign the manager role: Create a RegulatorManager instance linked to John's employee ID, then add this manager to the Regulator's authorizedManagers list.
4. Initiate a transaction: John (acting as the RegulatorManager) can now submit a SubmitRegulatoryAudit transaction on behalf of the National Environmental Agency, and the ACL/script checks will validate his authorization.

内容的提问来源于stack exchange，提问作者Rahul Singh