PutSQL失败时触发邮件告警：新增REL_ALERT代码未生效求助

Hey there, let's break down why your custom REL_ALERT setup isn't firing emails when PutSQL fails with Rollback on Failure=true enabled. I've worked through similar NiFi processor customization issues, so here are the key areas to check:

1. Verify REL_ALERT is Properly Defined & Registered #

First, make sure your new relationship is correctly added to the PutSQL processor's relationship set—NiFi won't recognize it otherwise.

• Check the Relationship Enum: Ensure you added REL_ALERT to the processor's relationship definition block:

  public static final Relationship REL_ALERT = new Relationship.Builder()
      .name("alert")
      .description("FlowFiles that trigger an alert on processing failure")
      .build();
  

• Add to getRelationships(): Don't forget to include it in the method that exposes relationships to NiFi's UI:

  @Override
  public Set<Relationship> getRelationships() {
      final Set<Relationship> relationships = new HashSet<>();
      relationships.add(REL_SUCCESS);
      relationships.add(REL_FAILURE);
      relationships.add(REL_ALERT); // Critical line—this makes the relationship visible
      return relationships;
  }
  

2. Fix the Trigger Logic in onTrigger() #

When Rollback on Failure=true, PutSQL's failure handling has specific session flow. Your custom code might be running at the wrong point in this sequence.

Common Mistake: Wrong Order of Operations #

The rollback operation resets uncommitted session changes, so you need to trigger the REL_ALERT after rolling back, but before committing the session. Here's how to adjust the failure catch block:

catch (final SQLException sqle) {
    getLogger().error("Failed to process SQL for {}: {}", new Object[] {flowFile, sqle.getMessage()}, sqle);
    
    // Execute rollback first if enabled
    if (rollbackOnFailure) {
        rollback();
    }
    
    // Transfer the failed FlowFile to REL_ALERT
    session.transfer(flowFile, REL_ALERT);
    
    // Optional: Keep sending to REL_FAILURE if needed (clone the FlowFile first)
    // session.transfer(session.clone(flowFile), REL_FAILURE);
    
    session.commit();
}

If you tried adding the transfer before the rollback, the session reset would likely cancel that routing action.

3. Validate UI Configuration & Connections #

Even if your code is correct, NiFi's UI setup can break the flow:

• Confirm the PutSQL processor now shows the "alert" relationship in its list of available relationships.
• Double-check that you've connected the "alert" relationship directly to your SendEmail processor.
• Verify the SendEmail processor is properly configured (SMTP server, authentication, recipient addresses)—it's easy to overlook this and blame the PutSQL customization.

4. Dig Into Logs for Clues #

Enable DEBUG logging for the PutSQL processor and check NiFi's nifi-app.log:

• Look for lines like Transferring flowFile [UUID] to relationship [alert] to confirm the routing is happening.
• Check for errors related to unregistered relationships, session state issues, or SendEmail failures—these will point you to the root cause quickly.

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