Batch Apex with SetParentLog() - no parent log available?

[JeroenSfdc]

I have implemented Nebula with Batch Apex using the documented pattern.
Although the Nebula__ParentLogTransactionId__c is set, the parent is not set through the Lookup Nebula__ParentLog__c.
Effectively, the parent transaction is not even created.

This is the pattern implemented. I initialize the member originalTransactionId in the constructor.

/**
@SuppressWarnings('PMD.AvoidGlobalModifier, PMD.ApexDoc')
global with sharing class Batch_xyz
        extends batchjobsch.BatchJobBase
        implements Database.Batchable<SObject>
                , Database.RaisesPlatformEvents
                , Database.Stateful {

    private final String originalTransactionId; // for Nebula

    global Batch_xyz() {
        originalTransactionId = Nebula.Logger.getTransactionId();
        Nebula.Logger.setParentLogTransactionId(originalTransactionId);
    }

    global Database.QueryLocator start(Database.BatchableContext batchableContext) {
        Nebula.Logger.setParentLogTransactionId(originalTransactionId);
        Nebula.Logger.info('Starting Batch_xyz');
        Nebula.Logger.saveLog();

        return Database.getQueryLocator(
        [
            SELECT
                Id
            FROM
                User
            WHERE
               ...
        ]);
    }

    global void execute(Database.BatchableContext batchableContext, List<User> scope) {
        Nebula.Logger.setParentLogTransactionId(originalTransactionId);
        Nebula.Logger.info('Execute phase Batch_xyz');
        Nebula.Logger.saveLog();
    }

    global void finish(Database.BatchableContext batchableContext) {
        Nebula.Logger.setParentLogTransactionId(originalTransactionId);
        Nebula.Logger.info('Finish Batch_xyz');
        Nebula.Logger.saveLog();
    } 
}

[JeroenSfdc]

So I found that if I actually do log an entry in the constructor, it works all logs created in the start, execute and finish phases are parented to the log created in the constructor. Am I using here a wrong pattern? In general it's fine, I can force to log in the same transaction where I call setParentLogTransactionId. But it's behaving different from what I expected?

global Batch_xyz() {
    originalTransactionId = Nebula.Logger.getTransactionId();
    Nebula.Logger.setParentLogTransactionId(originalTransactionId);
    Nebula.Logger.info('constructor Batch_xyz');
    Nebula.Logger.saveLog();
}

[jongpie]

Hi @JeroenSfdc sorry for the relate response on this! But I think this is working as expected:

• When you use setParentLogTransactionId(), it will always populate the field Log__c.ParentLogTransactionId__c
• If the parent transaction doesn't log anything itself, then there isn't a Log__c record created for it --> the child Log__c records will have a null value for Log__c.ParentLog__c (since there isn't a parent log that can be linked)
• If the parent transaction does log something (like you're doing in the constructor), then the child Log__c records will all have the lookup Log__c.ParentLog__c populated

If the original transaction doesn't log anything, then I don't have a way to accurately create a synthetic version of the parent Log__c record, so it's up to the original transaction to handle logging something if you want to have a true relationship between the records. And to help simplify reporting & list views, I've included the formula field Log__c.ParentLogLink__c that displays either a link to the parent Log__c (when Log__c.ParentLog__c is not null), or just the value of the field Log__c.ParentLogTransactionId__c (when Log__c.ParentLog__c is null)

Let me know if this makes sense, or if you see another way to handle it!

[JeroenSfdc]

Hi @jongpie I might need to test again - but what I saw is that with my provided code snippet (so without .saveLog() in the constructor) I had two separate, unrelated logs. I'd have expected the Nebula.Logger.info('Finish Batch_xyz'); to be linked to Nebula.Logger.info('Starting Batch_xyz');.

[jongpie]

Hi @JeroenSfdc, thanks for clarifying, I think I see the issue - I think it's because there are 4 transactions involved in your code, but it sounds like you're only expecting 3 transactions. With your current pattern, the log entry Nebula.Logger.info('Starting Batch_xyz'); in your start() method is not your parent transaction - it runs in a separate transaction from your constructor Batch_xyz() - so Nebula.Logger.info('Finish Batch_xyz'); won't be linked to Nebula.Logger.info('Starting Batch_xyz'); with your current code. At the moment, your code has these transactions running:

1. The constructor Batch_xyz() runs in the first transaction - this is the transaction that's calling your batch class via Database.executeBatch()
2. The start() method runs async as a second transaction - it's not the same transaction as the constructor
3. Each invocation of execute() runs as separate transactions
4. The finish method runs last

So, in your original example, your constructor setting the originalTransactionId was the problem

global Batch_xyz() {
    // Here, the value of Nebula.Logger.getTransactionId() is different than in the start() method
    originalTransactionId = Nebula.Logger.getTransactionId();
    Nebula.Logger.setParentLogTransactionId(originalTransactionId);
}

Depending on how you want to track the different transactions, you can either:

• Track all 4 keep using your latest version (where you now call Nebula.Logger.saveLog() inside the constructor Batch_xyz). This will result in 4 Log__c records, with the constructor's Log__c as the parent of the other 3 records. In this screenshot, there are 4 LogEntry__c records, each from a different transaction/Log__c record

  

• Only track the 3 transactions for the batchable methods start(), execute(), and finish. This is the pattern that I typically use (but both approaches are 100% valid) - I have an example class that uses this approach (my class doesn't even have a constructor declared).

  If you want to use this approach, then you could just move the logic that's currently in your constructor, and instead put it at the beginning of start():

  @SuppressWarnings('PMD.AvoidGlobalModifier, PMD.ApexDoc')
  global with sharing class Batch_xyz
          extends batchjobsch.BatchJobBase
          implements Database.Batchable<SObject>
                  , Database.RaisesPlatformEvents
                  , Database.Stateful {
  
      private String originalTransactionId; // for Nebula
  
      global Database.QueryLocator start(Database.BatchableContext batchableContext) {
          originalTransactionId = Nebula.Logger.getTransactionId();
          Nebula.Logger.setParentLogTransactionId(originalTransactionId);
          Nebula.Logger.info('Starting Batch_xyz');
          Nebula.Logger.saveLog();
  
          return Database.getQueryLocator(
          [
              SELECT
                  Id
              FROM
                  User
              WHERE
              ...
          ]);
      }
  
      global void execute(Database.BatchableContext batchableContext, List<User> scope) {
          Nebula.Logger.setParentLogTransactionId(originalTransactionId);
          Nebula.Logger.info('Execute phase Batch_xyz');
          Nebula.Logger.saveLog();
      }
  
      global void finish(Database.BatchableContext batchableContext) {
          Nebula.Logger.setParentLogTransactionId(originalTransactionId);
          Nebula.Logger.info('Finish Batch_xyz');
          Nebula.Logger.saveLog();
      } 
  }

  This approach will result in 3 Log__c records, with the start method's Log__c as the parent of the other 2 records. In this screenshot, there are 3 LogEntry__c records, each from a different transaction/Log__c record

  

[JeroenSfdc]

Thanks for the follow-up on this @jongpie it all makes sense now.

[jongpie]

Glad to hear it, let me know if you need anything else!