Callable implementation

[tscottdev]

New Feature Summary

I've been doing some POC for an implementation that provides a Callable interface to wrap the basic logging methods so that you can make use of the logger without having to create a hard package dependency. This is particularly useful if you want to add logging to your code but don't want to force your customers to have the nebula package installed. The package can then be installed during a period of investigation and later removed. I've written a callable implementation to wrap some of the basic functionality. If this is of interest to the project, I'd be happy to contribute this.

[jongpie]

Hi @tscottdev, thanks for the suggestion! Is there any chance you could share some of your POC code? Conceptually, I'm not a big fan of the Callable interface since it relies heavily on strings (instead of strongly-typed references), but I definitely think that there's value in the concept of having a way to log code without a hard dependency on having the full Nebula Logger package installed. I'd love to see how you've implemented it using Callable.

[tscottdev]

Thanks for the reply. I've just got a few hoops to jump through with the company I work for before I can send over the POC code. As soon as I get a green light I'll send it over. :)

[tscottdev]

Hi @jongpie, sorry for the delay. I've shared a repo with you that has some POC code in.

[jongpie]

Hi @tscottdev, thanks for sharing the repo with me! I won't be able to fully review it for a few days, but I'll try to review it & share my thoughts hopefully by this weekend.

[jongpie]

@tscottdev I've been tinkering with this idea some more, and unfortunately, it feels like too much extra code would be needed, and it would be difficult to support & maintain this feature (at least at this time). From a scalability perspective, it would be a big initial undertaking to make this work for all functionality in the current codebase, and it would become increasingly difficult to add support for new methods & functionality that are added to Nebula Logger in future releases. At least for now, I'm not going to move forward with adding this to the unlocked or managed packages.

But, another viable approach for optionally leveraging Nebula (when a customer does have it installed) is to create your own plugin/adapter package that depends on both your package and Nebula Logger's package. @jamessimone uses this approach in his project Apex Rollup. It avoids having a hard dependency in your primary package on Nebula Logger, while still providing a way to optionally integrate with Nebula Logger in customer orgs that have both installed. In Apex Rollup....

• His unlocked package has no dependencies / it can be installed independently of any other packages.
• Out of the box, it has its own Logger class, but has been designed to use dependency injection using an ILogger interface, so custom loggers can be created or installed in each customer's org
• When customers have both Apex Rollup & Nebula Logger installed, they can install Apex Rollup's optional Nebula Logger plugin package
  • This package has dependencies on both Apex Rollup's unlocked package & Nebula Logger's unlocked package, and the same concept should work if you'd rather depend on the managed package version of Nebula Logger (instead of the unlocked)

Based on the repo you shared, it feels like you already have a lot of the same concepts & approaches that @jamessimone has taken - the main difference is that you're using the Callable interface, and he's used an additional package (with package dependencies).

• Both approaches require your LoggerService class to support dependency injection, so I think both approaches are more or less "tied" in terms of effort & complexity of implementations
• With the Callable approach, both Nebula Logger & your package's implementation (LoggingServiceNebulaImpl) have to maintain hardcoded Strings, which is error prone since there would not be compile-time validations on the String values used.
• With a plugin package/package dependencies and interface usage, there's compile-time validation, both when developing the plugin package, as well as when generating package versions for the plugin package. This would avoid a lot of issues that could happen when using the Callable interface & String values

I think using a plugin package is a better solution overall (and wouldn't require any changes within Nebula Logger), but would love to hear your thoughts on this approach.

[mattandneil]

Winter '23 enables Apex to run Invocable Actions dynamically.

Here are the docs for the Invocable.Action classes and methods: developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Invocable_Action This will work with the Nebula managed package because the @InvocableMethod class is global:

Example usage for FlowLogEntry

// create the action by name, then setup one invocation
Invocable.Action.createCustomAction('apex', 'Nebula', 'FlowLogEntry')
.setInvocationParameter('savelog', true)
.setInvocationParameter('flowname', 'Test')
.setInvocationParameter('message', 'log_message')
.invoke();

However it doesn't work with the unlocked package due to a platform bug (Case 46476985)