11 Oct 18:27

jongpie

2445dcb

New synchronous JavaScript function getLogger() + deprecated async function createLogger()

This release is focused on several enhancements & bugfixes for logging in JavaScript (aura & lightning web components). Thanks to @jamessimone for reviewing & discussing the changes for this release, and thanks to @srikanth3107 for reporting issue #776!

Core Unlocked Package Changes

New `getLogger()` function

Partially fixed #728 by adding a new function getLogger() in logger LWC that can be called synchronously, and deprecated the async function createLogger()

This simplifies how developers use the logger LWC, and avoids some lingering JavaScript (JS) stack trace issues that occur in async functions
The function createLogger() is still supported & functional, but it's now considered deprecated since it requires using await (which is no longer necessary with getLogger())

Note

This does not truly "fix" or improve the stack trace parsing used in async functions, and async functions will continue to have inaccurate function names reported in some browsers (typically, eval is listed as the function name). This is a ongoing challenge in JavaScript due to what info is/isn't available in stack traces in some browsers (most notably, webkit browsers like Chrome & Edge).

But with the new getLogger() function, Nebula Logger no longer requires the use of async / await - and often the only reason developers were using async / await was to be able to use Nebula Logger. In these situations, developers can eliminate async / await, and the resulting log entries will have accurate JS function names.

Example: Old `createLogger()` Usage

Previously, JS developers had to use async, await, and truthy checks to ensure that Nebula Logger's LWC had finished being loaded. This resulted in more complexity for developers, who just want to be able to log some stuff 😢

import { createLogger } from 'c/logger';

export default class LoggerDemo extends LightningElement {
  logger;

  // Some lifecycle event (typically connectedCallback()) has to run async & await createLogger()
  async connectedCallback() {
    this.logger = await createLogger();
    this.logger.info('Hello, world');
    this.logger.saveLog();
  }

  // @wire functions run around the same time as connectedCallback(), but there's no guaranteed order
  // This result in some logging requiring truthy checks using the safe navigator "?.", and some loss of logging data could occur
  @wire(returnSomeString)
  wiredReturnSomeString({ error, data }) {
    this.logger?.info('>>> logging inside a wire function, if the logger is loaded');
    if (data) {
      this.logger?.info('>>> wire function return value: ' + data);
    }
    if (error) {
      this.logger?.error('>>> wire function error: ' + JSON.stringify(error));
    }
  }
}

Example: New `getLogger()` Usage

Now, await is no longer needed, and a logger instance can be immediately initialized & used. This results in less code, and happier developers 🥳

import { getLogger } from 'c/logger';

export default class LoggerDemo extends LightningElement {
  logger = getLogger();

  connectedCallback() {
    // Immediately use this.logger - no await, no truthy checks
    this.logger.info('Hello, world');
    this.logger.saveLog();
  }
}

  @wire(returnSomeString)
  wiredReturnSomeString({ error, data }) {
    // Immediately use this.logger - no await, no truthy checks
    this.logger.info('>>> logging inside a wire function');
    if (data) {
      this.logger.info('>>> wire function return value: ' + data);
    }
    if (error) {
      this.logger.error('>>> wire function error: ' + JSON.stringify(error));
    }
  }
}

New `exception()` function

Resolved #763 by adding a JS function equivalent to the Apex method Logger.exception(). Both of these do 3 things in 1 line of code:

Log an exception
Save the log
Rethrow the exception

Previously in JS, this would have been 3 lines of code:

this.logger.error('An error occurred').setExceptionDetails(someJSError);
this.logger.saveLog();
throw someJSError;

Now, 1 line of code provides the same functionality:

this.logger.exception('An error occurred', someJSError);

More Improvements for JS Stack Trace Parsing

Fixed #776 by updating logic in loggerStackTrace.js to better handle parsing when lightning debug mode is disabled
Previously, stack traces worked when debug mode was enabled, but was still inaccurate in some browsers when debug mode was off due to some subtle differences in the generated stack traces.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.12...v4.14.13

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oW3QAI
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oW3QAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oW3QAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oW3QAI

Contributors

jamessimone and srikanth3107

Assets 2

5 Join discussion

27 Sep 17:05

jongpie

v4.14.12

cfdae6b

Deprecated & replaced HttpRequestEndpoint__c fields with new HttpRequestEndpointAddress__c fields

Thanks to @ILambuRI for reporting this issue!

Core Unlocked Package Changes

Fixed #768 by deprecating the HttpRequestEndpoint__c fields on LogEntryEvent__e and LogEntry__c, and replaced them with new HttpRequestEndpointAddress__c fields that have a much longer max length (2,000 vs 255).

HttpRequestEndpoint__c fields are now considered deprecated since they're not capable of storing the full value of long endpoints
- The HttpRequestEndpoint__c fields will continue to be populated for the time being, and the value is now auto-truncated to 255 characters to fix the STRING_TOO_LONG error that was reported in #768
- The businessStatus on the fields has been updated to DeprecateCandidate
- The inlineHelpText on the fields has been update to Deprecated: instead use the field HttpRequestEndpointAddress__c
- The label on the fields has been update to DEPRECATED: HTTP Request Endpoint
Updated LogEntryRecordPage flexipage to have both HttpRequestEndpoint__c (existing) and HttpRequestEndpointAddress__c fields
- Both fields will be shown for now, and eventually HttpRequestEndpoint__c will be removed

Related context: this is essentially the same issue & solution used in release v4.13.15 for the now-deprecated text(255) fields BrowserUrl__c not being long enough, and they were replaced with new long textarea(2000) field BrowserAddress__c (PR #720). It's probably worth reviewing all of the text fields in the data model (especially some of the older fields) to see if it would make sense to take the same approach for any other existing fields.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.11...v4.14.12

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oV0QAI
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oV0QAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oV0QAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oV0QAI

Contributors

ILambuRI

Assets 2

0 Join discussion

25 Sep 01:25

jongpie

v4.14.11

ab92cd5

Bugfix: Updated Logger.setAsyncContext() behavior

Core Unlocked Package Changes

Updated the behavior of Logger.setAsyncContext() to only set the context the first time a non-null context value is provided
- Previously, subsequent calls would overwrite the context value, which wasn't really the intended behavior - it's intended to be used to set context at the beginning of a transaction

Pipeline Changes

Made some optimizations in build.yml so some steps don't run on draft PRs

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.10...v4.14.11

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oUgQAI
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oUgQAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oUgQAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oUgQAI

Assets 2

0 Join discussion

17 Sep 20:45

jongpie

v4.14.10

1629291

Double Feature: OmniStudio Logging + Loosely-Coupled Dependency Support

This release is a fun one - with one new Apex class, 2 great enhancements have been added to Nebula Logger

It's now even easier for ISVs, consultants, and package developers to optionally leverage Nebula Logger when its available in your customers' orgs
OmniStudio logging is now provided out of the box

Many thanks to @tscottdev for originally opening #371, as well as providing a very helpful sample implementation... and then waiting 2 years for me to finally be convinced that adding a Callable implementation is a great enhancement 😅

Thanks as well to all of the feedback & interest people have provided about adding support for OmniStudio logging, and to @jamessimone for the help with setting up a usable OmniStudio scratch org for testing

Core Unlocked Package Changes

New Support for Using Nebula Logger as a Loosely-Coupled Dependency

Resolved #371 by introducing a new CallableLogger Apex class that implements Apex's Callable interface - see the new wiki page for full docs.

This class provides dynamic access to Nebula Logger's core features - ISVs, consultants, and package developers can use this to optionally leverage Nebula Logger in a customer's org when it's available, without requiring a package dependency. For example, this sample code can be executed in any Salesforce org - and when Nebula Logger is available, 2 log entries will be saved.

// Dynamically create a instance Nebula Logger's Callable Apex class (if it's available)
Type nebulaLoggerCallableType = Type.forName('Nebula', 'CallableLogger') ?? Type.forName('CallableLogger');
Callable nebulaLoggerCallable = (Callable) nebulaLoggerCallableType?.newInstance();
if (nebulaLoggerCallable == null) {
  return;
}

// Example action: Add a basic "hello, world!" INFO entry
Map<String, Object> infoEntryInput = new Map<String, Object>{
  'loggingLevel' => System.LoggingLevel.INFO,
  'message' => 'hello, world!'
};
nebulaLoggerCallable.call('newEntry', infoEntryInput);

// Example action: Add an ERROR entry with an Apex exception
Exception someException = new DmlException('oops');
Map<String, Object> errorEntryInput = new Map<String, Object>{
  'exception' => someException,
  'loggingLevel' => LoggingLevel.ERROR,
  'message' => 'An unexpected exception was thrown'
};
nebulaLoggerCallable.call('newEntry', errorEntryInput);

// Example: Save any pending log entries
nebulaLoggerCallable.call('saveLog', null);

New Support for OmniStudio Logging

Resolved #644 by adding support for logging in OmniStudio, using the new CallableLogger Apex class - see the new wiki page for full docs. The included CallableLogger Apex class can be used in 2 places within OmniStudio:

OmniScript metadata
OmniIntegrationProcedure metadata

Once you've added logging in OmniStudio, any log entries generated in OmniStudio can be seen using the LogEntry__c object's included list view AllOmniStudioLogEntries

Slack Plugin Package Changes

Fixed #764 by correcting the logic used in SlackLoggerPlugin to format text fields containing line breaks

Thanks to @kacrouse for reporting this issue & providing the fix 🥳

Documentation Changes

Started rewriting & consolidating all documentation to live just in the wiki. Currently, content is split across the wiki, README.md, and the GitHub Pages site

README.md has been updated to link to wiki pages (instead of putting all content directly into README.md)
Eventually most of the content current in README.md will be removed/moved to the wiki

Pipeline Changes

Renamed all of the scratch definition files (again 😅 )
Updated build.yml so that 2 additional scratch orgs (6 total) are used for automated testing in the pipeline
- "Advanced" scratch org (formerly called the 'dev' scratch org) - existing scratch org, but was not previously used by the pipeline
- "OmniStudio" scratch org - new scratch definition file, used to validate that queries on OmniProcess work correctly, and to validate that sample OmniScript and OmniIntegrationProcedure metadata that leverage CallableLogger can successfully be deployed

Installation Info

Core Unlocked Package - no namespace

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oTdQAI
SFDX CLI: sfdx package install --apex-compile package --wait 20 --security-type AdminsOnly --package 04t5Y0000015oTdQAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oTdQAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oTdQAI

Slack Unlocked Package Plugin - no namespace

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oTTQAY
SFDX CLI: sfdx package install --apex-compile package --wait 20 --security-type AdminsOnly --package 04t5Y0000015oTTQAY
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oTTQAY
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oTTQAY

Contributors

tscottdev, kacrouse, and jamessimone

Assets 2

0 Join discussion

03 Sep 22:41

jongpie

v4.14.9

ff06c25

Bugfix: Apex code snippets auto-truncated

Core Unlocked Package Changes

Fixed #756 by truncating the Apex code snippets that are saved in the LogEntry__c fields OriginSourceSnippet__c and ExceptionSourceSnippet__c

Previously, the code snippet was only limited by the number of lines of code - but for Apex classes & triggers that have very looooooooooooong code on some lines, the code snippet could cause the JSON value to exceed the corresponding field's max length
Now, the code snippet only grabs the first 1,500 characters - both fields are set to a max of 2,000 characters, allowing 500 characters for the remaining JSON data

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.8...v4.14.9

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oSQQAY
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oSQQAY
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oSQQAY
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oSQQAY

Assets 2

0 Join discussion

02 Sep 17:46

jongpie

v4.14.8

5c4e09e

Added the ability to capture HttpRequest headers

Resolved #701 by providing a way to indicate which HttpRequest headers (and values) should be logged - previously, no header information was stored for HttpRequest objects.

Conceptually, this is the same idea as logging headers when calling the other LogEntryBuilder methods below:

setHttpResponseDetails(System.HttpResponse response)
setRestRequestDetails(System.RestRequest request)
setRestResponseDetails(System.RestResponse response)

However, there is one notable difference in the new behavior for logging HttpRequest headers - the HttpRequest class does not have a method to get all of the header keys, so you must explicitly tell Nebula Logger which header keys you want to log.

Core Unlocked Package Changes

Added instance method overload LogEntryEventBuilder.setHttpRequestDetails(System.HttpRequest request, List<String> headersToLog)
- Any header keys provided in headersToLog will now be logged
- The existing overload, setHttpRequestDetails(System.HttpRequest request), will not log any header information
Added new LogEntryEvent__e fields HttpRequestHeaderKeys__c and HttpRequestHeaders__c to capture the specified list of header keys
- The new fields mimic these existing fields:
  - HttpResponse header data stored in HttpResponseHeaderKeys__c and HttpResponseHeaders__c
  - RestRequest header data stored in RestRequestHeaderKeys__c and RestRequestHeaders__c
  - RestResponse header data stored in RestResponseHeaderKeys__c and RestRequestHeaders__c
Added new LoggerParameter__mdt record StoreHttpRequestHeaderValues to globally control if HttpResponse header values are stored when calling setHttpRequestDetails(System.HttpRequest request, List<String> headersToLog)
- This new record mimics the existing record StoreHttpResponseHeaderValues (used for responses)
Added new LogEntry__c fields to store the HttpRequest header keys & values captured on LogEntryEvent__e, as well as some checkbox fields to aid with filtering in SOQL, list views, etc.
- HttpRequestHeaderKeys__c
- HasHttpRequestHeaderKeys__c - set to true when HttpRequestHeaderKeys__c is not null
- HttpRequestHeaders__c
- HasHttpRequestHeaders__c - set to true when HttpRequestHeaders__c is not null
Updated the flexipage LogEntryRecordPage to add the 2 new LogEntry__c fields HttpRequestHeaderKeys__c and HttpRequestHeaders__c
- Both fields are conditionally displayed when populated, based on their corresponding checkbox fields HasHttpRequestHeaderKeys__c and HasHttpRequestHeaders__c (respectively)
Updated the existing list view AllHttpRequestLogEntries to include the new field HttpRequestHeaderKeys__c (HttpRequestHeader__c is intentionally not included at this time)

Example

This example Apex script will create a LogEntry__c record with data about the HttpRequest - including the 2 specified header keys & their values.

System.HttpRequest httpRequest = new System.HttpRequest();
httpRequest.setBody('{ "hello": "world" }');
httpRequest.setEndpoint('https://fake.salesforce.com');
httpRequest.setHeader('some-header', 'some value');
httpRequest.setHeader('another-header', 'another value');
httpRequest.setMethod('GET');

List<String> headersToLog = new List<String>{ 'some-header', 'another-header' };
Logger.info('logging an HTTP request').setHttpRequestDetails(httpRequest, headersToLog);
Logger.saveLog();

Pipeline Changes

Updated build.yml to fail the build if the codecov upload action fails

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.7...v4.14.8

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oS1QAI
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oS1QAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oS1QAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oS1QAI

Assets 2

0 Join discussion

28 Aug 18:52

jongpie

v4.14.7

a99f380

Bugfix: overzealous data masking rule for US social security numbers

Core Unlocked Package Changes

🐞 Fixed #542 (almost exactly 1 year after it was opened😅) to use a more targeted regular expression for identifying US social security numbers (SSN) to mask. Previously, the rule was not restrictive enough in the regular expression used in SensitiveDataRegEx__c, which resulted in the rule masking some values that it should have ignored.

For example, logging a message containing a (fake) credit card number like Here is a value 5000-1111-2222-0005 and it looks like a Mastercard number, so apply the Mastercard masking rule...

Previously, this would unintentionally have applied the SSN rule instead, resulting in the value being masked as...
- Here is a value XXX-XX-1111-2222-0005 and it looks like a Mastercard number, so apply the Mastercard masking rule
Now, the US SSN has been corrected, and false-positive matches like credit card numbers will either be correctly masked (using their own matching credit card rule), or ignored (if not a valid SSN or credit card)
- Here is a value ****-****-****-0005 and it looks like a Mastercard number, so apply the Mastercard masking rule

🤏 And a little bit of scope creep included:

Made a small optimization in the Apex class ComponentLogger to cache the field map for LogEntryEvent__e once per transaction
- This map is used internally to validate & set custom fields in JavaScript, which was added in release v4.14.6
- Previously, ComponentLogger would re-call the describe method for LogEntryEvent__e every time there was a component log entry that was setting 1 or more custom fields

Pipeline Changes

Updated pipeline script scripts/build/validate-custom-metadata-records.apex to validate that the regex values in LogEntryDataMaskRule__mdt work as expected

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.6...v4.14.7

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oRrQAI
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oRrQAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oRrQAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oRrQAI

Assets 2

0 Join discussion

28 Aug 02:37

jongpie

v4.14.6

2894401

Custom Field Mappings Support for Lightning Components

Core Unlocked Package Changes

Resolved #718 by adding the ability to set custom fields on a log entry in JavaScript (lightning components), using a new function setField() in logEntryBuilder.js. This is the JavaScript equivalent to the Apex method overloads setField() in LogEntryEventBuilder.cls that were introduced in release v4.13.14.

To use the new setField() function, pass an object as the function's single parameter. The object should contain the custom fields on LogEntryEvent__e that you want to set, along with their corresponding values. For example: { SomeField__c": "some value", "AnotherField__c": "another value" }

import { createLogger } from "c/logger";

export default class LoggerCustomFieldDemo extends LightningElement {
  logger;

  async connectedCallback() {
    this.logger = await createLogger();

    this.logger.info("Hello, world! This log entry has 2 custom fields set.")
      .setField({
        SomeCustomTextField__c: "some text value",
        SomeCustomNumberField__c: 123,
      });

    this.logger.debug("Hello again, world! This log entry has 1 other custom field set.")
      .setField({
        AnotherCustomTextField__c: "another text value",
      });

    this.logger.saveLog();
  }
}

Note

The code above only highlights the new functionality that is now available when logging in lightning components. For more info on how to fully set up custom field mappings, see this section in README.md.

Recipes Metadata Changes

Updated the demo lighting components in the recipes metadata folder to set a custom field on LogEntry__c. This provides a quick & easy way to verify that the functionality works for lightning components.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.5...v4.14.6

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oRhQAI
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oRhQAI
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oRhQAI
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oRhQAI

Assets 2

0 Join discussion

27 Aug 18:16

jongpie

v4.14.5

4fe4c36

Added loggerSettings LWC to utility bar

Core Unlocked Package Changes

Added the Logger Settings component to the Logger Console app's utility bar, which makes it much easier to access. This component is still available on the app's homepage, as well as via a custom tab - but those locations aren't always convenient if you are trying to view existing logging data + quickly adjust settings. Accessing it via the utility bar can be done at any point in the console app.

Updated loggerSettings LWC to support the target lightning__UtilityBar (in addition to the 2 targets it previously had, lightning__HomePage and lightning__Tab)
Added loggerSettings LWC to the flexipage LoggerConsoleUtilityBar
Updated lightning-datatable in loggerSettings LWC to have the property wrap-table-header, which helps make the column headers more readable when shown in the utility bar

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.4...v4.14.5

SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oRXQAY
SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oRXQAY
Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oRXQAY
Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oRXQAY

Assets 2

0 Join discussion

26 Aug 14:59

jongpie

v4.14.4

2462fca

Optionally Auto-Call lightning-logger LWC