Salesforce (im_salesforce)

This module can be used to collect event monitoring data from Salesforce applications. It uses Salesforce Lightning Platform SOAP API and REST API v54 with username-password authorization to retrieve log data.

For the module to connect to the API and access Salesforce logs, you must first set up a Connected App and retrieve its Consumer Key and Consumer Secret.

To examine the supported platforms, see the list of installer packages in the Available Modules chapter.

Configuration

The im_salesforce module accepts the following directives in addition to the common module directives.

The following directives are required to authenticate with the REST API.

ConsumerKey: This mandatory directive specifies the consumer key of your Salesforce Connected App.

ConsumerSecret: This mandatory directive specifies the consumer secret of your Salesforce Connected App.

Domain: This mandatory directive specifies the domain of your Salesforce org, e.g., MyDomainName.my.salesforce.com.

LoginDomain: An optional directive to specify a different domain for OAuth application authorization. By default, login.salesforce.com is used. For sandbox environment, specify test.salesforce.com.

Password: This mandatory directive specifies the password of your Salesforce org account.

ApiVersion: This optional directive specifies the used Salesforce REST API version. It can be in v57.0 or 57 form.

CADir

This directive specifies a path to a directory containing certificate authority (CA) certificates. These certificates will be used to verify the certificate presented by the remote server. The certificate files must be named using the OpenSSL hashed format, i.e. the hash of the certificate followed by .0, .1 etc. To find the hash of a certificate using OpenSSL:

$ openssl x509 -hash -noout -in ca.crt

For example, if the certificate hash is e2f14e4a, then the certificate filename should be e2f14e4a.0. If there is another certificate with the same hash then it should be named e2f14e4a.1 and so on.

A remote server’s self-signed certificate (which is not signed by a CA) can also be trusted by including a copy of the certificate in this directory.

The default operating system root certificate store will be used if this directive is not specified. Unix-like operating systems commonly store root certificates in /etc/ssl/certs. Windows operating systems use the Windows Certificate Store, while macOS uses the Keychain Access Application as the default certificate store. See NXLog TLS/SSL configuration in the User Guide for more information on using this directive.

EventFilter

This is an optional group directive to include or exclude event types from being collected. If this directive is not specified, the module will collect all events. It has the following sub-directives that can be defined multiple times:

Accept

Specifies a list of comma-separated event types to collect.

Exclude

Specifies a list of comma-separated event types to exclude from being collected.

The Accept and Exclude directives are mutually exclusive. If Accept is specified, the module downloads only events matching the listed event types. If Exclude is specified, the module downloads all events except the listed event types.

PollInterval: This optional directive specifies how frequently the module will check for new events in seconds. If this directive is not specified, it defaults to 60 seconds.

ReadFromLast

This optional boolean directive instructs the module to only read logs that arrive after NXLog is started. This directive comes into effect if a saved position is not found, for example on first start, or when the SavePos directive is FALSE. When the SavePos directive is TRUE and a previously saved position is found, the module will always resume reading from the saved position. If ReadFromLast is FALSE, the module will read all the available logs. This can result in a lot of messages and is usually not the expected behavior. If this directive is not specified, it defaults to TRUE.

The following matrix shows the outcome of this directive in conjunction with the SavePos directive:

ReadFromLast SavePos Saved Position Outcome

ReadFromLast	SavePos	Saved Position	Outcome
`TRUE`	`TRUE`	No	Reads events that are logged after NXLog is started.
`TRUE`	`TRUE`	Yes	Reads events from saved position.
`TRUE`	`FALSE`	No	Reads events that are logged after NXLog is started.
`TRUE`	`FALSE`	Yes	Reads events that are logged after NXLog is started.
`FALSE`	`TRUE`	No	Reads all events.
`FALSE`	`TRUE`	Yes	Reads events from saved position.
`FALSE`	`FALSE`	No	Reads all events.
`FALSE`	`FALSE`	Yes	Reads all events.

TRUE

Reads events that are logged after NXLog is started.

TRUE

Yes

Reads events from saved position.

TRUE

FALSE

Reads events that are logged after NXLog is started.

TRUE

FALSE

Yes

Reads events that are logged after NXLog is started.

FALSE

TRUE

Reads all events.

FALSE

TRUE

Yes

Reads events from saved position.

FALSE

Reads all events.

FALSE

Yes

Reads all events.

SavePos: If this boolean directive is set to TRUE, the timestamp of the last read event will be saved when NXLog exits. The timestamp will be read from the cache file upon startup. The default is TRUE, the last timestamp will be saved if this directive is not specified. This directive affects the outcome of the ReadFromLast directive. The SavePos directive can be overridden by the global NoCache directive.

StartFrom: This optional directive specifies the time in RFC 3339 format of the first event to pull. If this directive is not set, the module reads events according to the ReadFromLast directive.

Sandbox environment

If a sandbox environment is used, the following configuration changes should be applied:

LoginDomain should be test.salesforce.com.
Domain should be changed to MyDomainName—SandboxName.sandbox.my.salesforce.com.
Login should be appended with .sandbox_name: for example, user1@acme.com becomes user1@acme.com.test.

Examples

Example 1. Collecting Salesforce logs

This configuration collects event monitoring logs from a Salesforce organization. im_salesforce receives records from the Salesforce API in CSV format, which it then parses into structured data and writes each record as a list of key-value pairs.

nxlog.conf

<Input salesforce>
    Module            im_salesforce
    Domain            MYACCOUNT.my.salesforce.com
    LoginDomain       login.salesforce.com
    Login             USER@email.com
    Password          USERPASSWORD
    ConsumerKey       APP_KEY
    ConsumerSecret    APP_SECRET

    <EventFilter>
        Accept      Login,Logout (1)
        Accept      OneCommerceUsage

        # Exclude   Search,SearchClick (2)
        # Exclude   Sandbox
    </EventFilter>

    StartFrom         2022-07-19T16:39:57-08:00 (3)
    PollInterval      120 (4)
</Input>

1	The event filter specifies the list of event types to collect in the Accept sub-directives.
2	The filter can also be configured to collect all log types except those specified by the Exclude sub-directives.
3	The StartFrom directive specifies to start collecting events from the specified date onward.
4	The PollInterval directive specifies to check for new events every 120 seconds. The default is 60 seconds.

Output sample

The following is a Salesforce event monitoring record after it was processed by NXLog.

2022-07-15 12:03:11 nxlog-server INFO EVENT_TYPE="OneCommerceUsage" TIMESTAMP="20220602110049.842" REQUEST_ID="4jHvZvFIY-2Rl-l1cKNLKV" ORGANIZATION_ID="00D5f000003Hhp1" USER_ID="0055f0000030qMF" RUN_TIME="14443623" CPU_TIME="6876485" SERVICE_NAME="CommerceLicenseUsageMetrics" OPERATION="B2BMetricsCombinationJob" OPERATION_STAGE="combineNumberOfStores" COUNT="0" OPERATION_STATUS="Success" CONTEXT_MAP="{\"cc\":0,\"lb2b\":0}" B2B_EDITION="LB2B" TIMESTAMP_DERIVED="2022-06-02T11:00:49.842Z" USER_ID_DERIVED="0055f0000030qMFAAY"