For the complete documentation index, see llms.txt. This page is also available as Markdown.

Developer guide

The guide is intended for Salesforce developers with hands-on experience. If you're a Salesforce admin user with very little to zero experience in software development, you might want to check out the Business user guide instead to learn how to manage the Spark integration.

Getting started

Feel free to skip this section If you’re already familiar with developing Salesforce (SF) applications. For those who need a refresher, this section covers the basic concepts of Salesforce development.

There are multiple ways to develop a Salesforce application. The most common method is to use the Developer Console, a web-based integrated development environment (IDE). Alternatively, many developers prefer Visual Studio Code (VSCode), which offers a more user-friendly and versatile experience. Before diving in, review the Get Ready to Develop guide on Trailhead.

When using the VSCode approach, it’s important to understand that your local project directory mirrors the structure of Salesforce components in the connected DevHub or Scratch Org. In essence, Salesforce artifacts—such as Apex classes, triggers, and SOQL queries—are represented as files in the project. While most actions you perform in VSCode are executed directly in the Salesforce Org, some exceptions exist, which is irrelevant for this guide.

This development model differs from traditional software development. Think of it as a convenient way to interact with Salesforce components, manage version control, and bundle subsets of components for packaging and deployment, such as publishing apps on AppExchange.

Salesforce Architecture (Source: Trailhead)

If this seems abstract now, don’t worry — it will all make sense as you progress through the development process.

At the end of this guide, you will be able to:

  • Create, edit, and query custom metadata objects.

  • Create and update Apex classes, including unit tests.

  • Create and update Lightning Web Components.

Prerequisites
  • Access to Salesforce DevHub or Org

  • Access to a Coherent Spark account

Additional tools if you're using VSCode are:

Remember to create a scratch org as your developer workspace to avoid introducing unnecessary and/or breaking changes.

Development process

Your primary objective with this integration is to utilize Coherent Spark's Execute API to trigger and invoke your externalized calculations. In simple terms, this involves invoking callouts using Apex.

You can think of the Salesforce development process as being divided into three main phases:

  1. Backend development: create or update Apex classes to manage your integration logic;

  2. Frontend development: create or update Lightning Web Components for user interaction;

  3. Custom metadata: define your Spark configurations as needed.

Phase 1: Backend development

In the backend phase, you’ll use Apex classes to represent the input and output data required by your calculation engine. Since Apex is a structurally-typed language, your classes must match the JSON structure expected by the version of Execute API you choose to work with.

Sample SparkClient base class
Apex Classes in VSCode

In VSCode, you’ll need to create two files:

  1. force-app/main/default/classes/SparkClient.cls

    • This Apex class handles HTTP requests to Spark using the configured settings.

    • You can either hardcode these settings or use custom metadata to fetch them dynamically.

    • Keep in mind: these settings may include user credentials, so they must be handled securely.

  2. force-app/main/default/classes/SparkClient.cls-meta.xml

    • This metadata file is essential for deploying the Apex class to your Salesforce org.

    • It provides Salesforce-specific details about SparkClient.cls, such as its name, description, and visibility settings.

Important Note: If there’s a syntax error in your Apex class—something the IDE might not catch—the deployment will fail. Yes, it’s not the smooth developer experience you were hoping for, but that’s how Salesforce operates. Always remember: changes made in VSCode are merely a local representation of what’s actually implemented in Salesforce.

To harness SparkClient.cls, let's now implement a basic use case simulating a callout to Spark service.

Sample SparkClient class

The example above of a callout service implementation uses dummy data to refer to Spark settings needed to trigger the calculation engine residing in Coherent Spark. In a real-world scenario, you would want to collect your input data as a custom object from SF, then feed it into Spark to run complex calculations, and finally collect the output data as part of your business data for further processing.

Below is what you'll need to add more unit tests to your test suite for SparkClient.cls:

  1. An HTTP callout mock class to simulate what the backend service would respond with based on a given request.

  2. Then, the actual unit tests for the SparkClient.cls and SparkService.cls.

Further readings on Apex classes can be found here:

Phase 2: Front-end development

The frontend phase might feel more approachable than the backend development, mainly because it’s more visual and interactive. That is, you'll be creating user-interactive components to enhance the user experience for Salesforce admins.

If you’re already familiar with web development technologies like HTML, CSS, and JavaScript, you’ll find this phase straightforward. If you’re not a web developer, we recommend starting with the LWC Guide to help you understand the basics of Lightning Web Components (LWC) before you can proceed. Roughly speaking, LWC is a Salesforce-proprietary modern framework for building web components. The following resources can help you grasp how LWC works behind the scenes:

LWC Setup in VSCode

In VSCode, your project should look more or less like this:

The files listed above are usually used to configure the LWC block of the Salesforce project. While some of them aren’t mandatory, they play a crucial role in maintaining code quality and consistency. For instance, they help enforce coding standards such as linting and formatting and facilitate running unit tests locally using Jest.

Here’s a quick recall of key tools you should consider installing:

  • Prettier: Ensures consistent code formatting.

  • ESLint: Enforces coding standards and identifies potential issues.

  • Jest: Enables running unit tests locally.

  • Husky: Runs pre-commit hooks to enforce linting, formatting, and tests before committing changes.

Here's an LWC example using the existing backend service SparkService.cls:

Phase 3: Custom Metadata

Custom metadata in Salesforce stores reusable, deployable configurations for application logic, such as business rules or integration settings. It’s ideal for static data, as records can be queried in Apex without consuming SOQL limits.

Custom metadata also supports custom fields, declarative setup, and seamless deployment between orgs, making it a powerful tool for centralizing and managing configurations efficiently. Hence, it makes sense to store Spark settings such as base URL, tenant name, API key, or other static resources there.

In the example below, an anonymous Apex script (a more direct way to execute Apex code directly in the SF org) is used to query the defined custom metadata object Spark_Settings__mdt and print its content.

What's next?

This was a brief explanation of how to bring your Excel-based calculation logic to Salesforce. There's definitely more that can be done with Spark within Salesforce. Please reach out to the Coherent Sales team for more information.

Last updated