Setting Origin__c on LogEntry__c

[TKGC]

Is there a simple way in APEX to set the Origin__c value of a LogEntry__c record?
I am considering the possibility of creating an abstract wrapper class (e.g. MyOrgLogHandler) to be utilized to handle logging operations within my org. In addition to decoupling, it could also abstract Logger.saveLog() from users.

For example: MyOrgLogHandler.logInfoMessage('message');

However, wrapping the Logger calls within a custom MyOrgLogHandler class will result in the LogEntry__c.Origin__c value being set to MyOrgLogHandler - and therefore not provide that added useful peice of information in the LogEntry details.
Is there a way to override the Origin of the LogEntry record? (e.g. setting it to the last value parsed from the stack trace)

This may also open the possibility to abstract managing the Log__c.ParentLog__c to relate logs across transactions for a user session when applicable - I am still trying to figure out how to go about this for user session scenarios beyond Batchable and Queueable Jobs (which already have clear examples provided in the documentation). I would also be appreciative of any suggestions to this end.

Any thoughts or input is much appreciated. Thank you!

[jongpie]

Hi @TKGC - right now, you could manually set the origin of the entry using something like this:

Logger.info('hello, world').getLogEntryEvent().OriginLocation__c = 'some value';

Essentially, whatever value you set on the platform event's field OriginLocation__c is ultimately what's stored in LogEntry__c.OriginLocation__c (which is used in the formula field LogEntry__c.Origin__c). I don't think this approach is ideal, as you would need to add additional logic to fully handle parsing a stack trace (which is something Nebula Logger already does internally), but it's something you could implement today. However, I already have some internal logic built to skip some classes when setting the field OriginLocation__c - I'll look into the possibility of making this list of classes configurable using the custom metadata type LoggerParameter__mdt, I think that would be the better long-term solution for this kind of situation.

A couple of follow up questions for you though, as I'm curious about your use case:

• Other than decoupling the rest of your code from Nebula Logger, what's the advantage of introducing your MyOrgLogHandler class? Offhand, it sounds like potentially an unnecessary extra layer, but I'd love to hear more about why you're considering using this approach (instead of just calling Logger directly throughout your codebase)
• Can you clarify what you mean by "abstract Logger.saveLog() from users?"
• Can you clarify what you mean by "abstract managing the Log__c.ParentLog__c to relate logs across transactions for a user session when applicable?"

[TKGC]

Thanks @jongpie!! Will do.

[kevlar8]

Hi @jongpie, this feature looks exactly like what I need as I have a requirement to decouple our logging.

I tried it out but I see that my requirement is slightly different in that I have two levels of classes before I call the Nebula Logger class

i.e. MyClass -> MainLogger -> NebulaWrapper -> Logger

So I tried
Logger.ignoreOrigin(MainLogger.class);
Logger.ignoreOrigin(NebulaWrapper.class);

Which does remove the named classes from the stack trace which is great.

But what I am seeing in the origin field is the value Apex.External entry point and I am also seeing External entry point as the first line of the stack trace and not MyClass.

Is there any way to get around this?

[jongpie]

Hi @kevlar8, that's very strange, I've not previously seen the origin field/stack trace populate with 'External entry point'. Could you try adding this line to your method in MyClass? This will print out the original, unmodified stack trace - it may contain some details that you don't want to share publicly, but can you see if this also includes 'External entry point' in the output?

public class MyClass {
  public static void someMethod() {
     // You can add this codeto your existing method, and then see what it outputs in developer console or the LogEntry__c object
     Logger.debug('>> The original stack trace: ' + new DmlException().getStackTraceString());
     Logger.saveLog();
  }
}

[kevlar8]

Hi @jongpie, thanks for investigating this.

I added the above code to my init method and got Apex.MyClass.init set in the Origin and could not see "Apex.External entry point" in the stack trace.

One other thing i found out is that if I only have one level of calls before the wrapper
i.e. MyClass -> NebulaWrapper -> Logger

I do not get Apex.External entry point in the stack trace. It seems to be that extra level of call that causes the issue for me.

[jongpie]

That's really interesting, thanks for sharing @kevlar8 - I've not seen that issue before, but I'll try to setup some similar classes to see if I can recreate it. Offhand, I don't know of a solution, but I'll do some research to see if anything can be done to better handle this scenario.