如何在Hyperledger Composer中运行持续监控函数以实时更新资产？

Great question—let’s break this down clearly, because Hyperledger Composer (and its underlying Hyperledger Fabric layer) has hard constraints around long-running logic that you need to work with.

First off: you cannot run persistent, continuous logic directly inside your logic.js chaincode. Chaincode functions are stateless, short-lived, and only execute when triggered by a transaction. Any infinite loops or ongoing polling inside chaincode will either time out, hog peer resources, or fail entirely.

Instead, the right approach is to offload the continuous work to an external service, which interacts with your Composer network on a schedule or in response to events. Here are the two most practical solutions:

1. External Scheduled Task Service (Best for Full-Time Monitoring) #

Set up an external script or service that periodically connects to your Composer network, fetches assets, runs your API checks, and submits transactions to update assets. This keeps heavy lifting outside the blockchain while using Composer’s tools to interact with the network.

Example Node.js Implementation #

Use tools like node-schedule for scheduling, plus the Composer Client SDK to interface with your network:

const BusinessNetworkConnection = require('composer-client').BusinessNetworkConnection;
const schedule = require('node-schedule');

// Core function to execute monitoring and updates
async function runPlaneMonitoring() {
    let connection;
    try {
        // Connect to your business network with an authorized identity
        connection = new BusinessNetworkConnection();
        await connection.connect('admin@your-network-identifier');

        // Fetch all Plane assets from the registry
        const assetRegistry = await connection.getAssetRegistry('org.your-domain.Plane');
        const planes = await assetRegistry.getAll();

        // Submit your existing monitoring transaction
        await connection.submitTransaction('org.your-domain.repeatMonitorPlane', planes);

        console.log(`Completed monitoring cycle for ${planes.length} planes`);
    } catch (error) {
        console.error('Monitoring cycle failed:', error.message);
        // Add retry logic here for API timeouts or network glitches
    } finally {
        if (connection) await connection.disconnect();
    }
}

// Schedule to run every 5 minutes (adjust cron syntax for your needs)
// Cron format: minute, hour, day, month, weekday
schedule.scheduleJob('*/5 * * * *', runPlaneMonitoring);

// Run immediately when the script starts
runPlaneMonitoring();

Production-Grade Tips #

• Use a reliable scheduler: For production, avoid running a simple Node.js script on a single machine. Opt for Kubernetes CronJobs, cloud services (like AWS CloudWatch Events or Azure Logic Apps), or Linux cron on a dedicated server.
• Secure authentication: Ensure your external service uses a valid Composer identity with permissions to read assets and submit transactions. Store credentials securely (e.g., environment variables, secret managers).
• Build idempotent transactions: Make sure repeatMonitorPlane is idempotent (running it multiple times doesn’t cause unintended side effects) in case the scheduler retries a failed cycle.
• Monitor the monitor: Set up alerts for failed cycles (via email, Slack, or tools like Prometheus) to catch issues early.

2. Event-Driven Monitoring (For Targeted Updates) #

If you don’t need to poll all assets nonstop, you can listen for blockchain events (like when a Plane asset is created or updated) and trigger your API checks only when an event occurs. This is more efficient for event-driven use cases.

How to Implement #

1. In your logic.js, emit an event whenever a Plane asset changes:

   // Inside your asset update transaction
   const planeUpdatedEvent = getFactory().newEvent('org.your-domain', 'PlaneUpdated');
   planeUpdatedEvent.plane = plane;
   emit(planeUpdatedEvent);
   

2. Build an external service that listens for this event using the Composer SDK. When the event fires, run your API checks and submit an update transaction if needed.

Why Not Run This Inside Chaincode? #

To hammer this home:

• Chaincode runs in a sandbox with strict execution time limits (Fabric defaults to 30 seconds). Long loops will time out instantly.
• Chaincode is stateless—each transaction execution is isolated, so you can’t maintain persistent connections to external APIs.
• Persistent logic in chaincode would tie up Fabric peer resources, degrading performance for all other network transactions.

内容的提问来源于stack exchange，提问作者Simon Mullaney