DEV Community: Jason Sun

Automating Developer Workflows and Deployments on Salesforce and Heroku

Jason Sun — Thu, 11 Mar 2021 15:49:23 +0000

(Heroku and Salesforce - From Idea to App, Part 13)

This is the 13th and last article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”). eCars allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Automating Business Processes Using Salesforce Flows and APEX

Scale Salesforce Apps Using Microservices on Heroku

More Scaling Salesforce Apps Using Heroku Microservices

Javascript Unit Testing

APEX Unit Testing on Salesforce

Deploying Salesforce and Heroku Apps with Ease

I’ve been following this Trailhead Live video series to brush up and stay current on the latest app development trends on these platforms that are key for my career and business. I’ll be sharing each step for building the app, what I’ve learned, and my thoughts from each session. These series reviews are both for my own edification as well as for others who might benefit from this content.

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

Last time, we went over methods of packaging and deploying applications with npm with Javascript as well as several frameworks for packaged and unpackaged development for Salesforce.

Now that we’ve built and deployed our eCars app, it makes sense that the capstone session of this series reviews the overall application development lifecycle and also covers some ways to automate these processes to make our lives as developers easier.

Application Development Lifecycle

Every application, even when successful, requires maintenance, upgrades, and feature additions in order to stay relevant and keep up with the rapidly changing software application world. As a result, we need a well-regimented process for releasing with confidence that avoids common pitfalls when tinkering with an application’s code that is already out in the wild as well as when many developers are working on a single codebase. Collectively, this is referred to as “Application Lifecycle Management” or ALM. Some examples of things that we want to avoid and problems we want to solve with ALM are:

Developers’ changes getting overwritten by other developers’ changes and deployments
Not knowing exactly what changes are going into a release
Knowing a change was made to the app but not knowing who made it, when, and why
Manually managing the release process and deploy code
Releasing a change, having it break critical functionality, and the need to roll it back easily

For Salesforce admins who have used Changesets to push releases from sandboxes to Production, you are all probably intimately familiar with the gaps that that release model creates. Ever try to quickly roll back a Changeset? It’s basically not possible…

This is why the modern application lifecycle management model involves multiple steps and tools that help make this process more effective.

Modern Application Lifecycle Management (ALM)

As you can see, we have tools and processes for each major step of ALM. Most of these elements have been covered in previous articles in this series from IDEs/CLIs/extensions to help developers manage code to automated unit tests.

Continuous Integration/Deployment for Salesforce

In my opinion, a major key for Salesforce administrators and developers is to shift away from a limiting “org-based” development model where the production and sandbox orgs themselves serve as the source of truth of the application to a source-driven development model. In a source-driven model, the source code, managed in git, serves as the source of truth. After adopting this concept, it becomes much easier to work with ALM and avoid some of the problems mentioned above.

An example of such source-driven development and automation can be seen in the diagram below.

Source-driven Automation

Using a git repository that houses the Salesforce application’s code, we can manage the environments (orgs) and branches of the application to avoid things like overwriting code and allow for precise tracking of features and fixes.

Rather than simply deploying changes directly from sandbox to production with a difficult-to-track and impossible-to-rollback changeset, a source drive automation could proceed as follows:

The admin/developer checks out a new feature branch from the most up-to-date branch
The admin/developer makes their changes to the app in a sandbox or scratch org and then verifies and commits their changes to their feature branch
They then make a “pull request” to an upstream branch such as an integration or QA/UAT branch that is tied to a dedicated integration or QA sandbox (typically a partial or full copy). In this step, GitHub does some magic and compares the pull request to the target branch and detects if there are any conflicts in the code that need to be resolved before merging the pull request. Typically you’ll also want to require the developers to write a summary of the pull request and have reviewers review the pull request before merging it. This is where you can prevent developers from overwriting code as well as other quality checks.
Automated unit and regression tests can also be invoked around this step to make sure that all automated tests pass.
The updated codebase can then be deployed to the QA or UAT Salesforce environment for demos and end-user testing.
If all passes there, then you can version the QA/Integration branch and merge it into the production branch that is tied to the Production environment. Here, you can have a continuous deployment or continuous integration job automatically deploy the updates from the branch to the target production org to save time deploying things manually.

While this list may seem longer than a simpler deployment model, using source management tools like Github and Github Actions and continuous integration/continuous deployment (CI/CD) or DevOps workflow tools like Copado and Gearset can significantly automate and streamline this process. Sometimes the deployment of certain functionality may involve not just metadata but data in the objects themselves, such as when important configuration information in managed packages are stored in the object data layer. In this case, Github wouldn’t be able to help with tracking and deploying the data itself. And for these situations, I like to use tools like Prodly and sfAPEX to help manage deployments that involve actual data.

Heroku Deployments and Heroku Flow

In a previous article, we deployed our Heroku application from the CLI from our local repository directly to Heroku. To involve Github workflows into this process and take advantage of all of the source control features of Github, we can create an integration between Heroku git and Github so that once our code changes get pulled to a certain branch, such as the production or master branch. The updates get deployed automatically to our live Heroku app thus automating a repetitive aspect of the developer workflow.

To make this magic happen, we can use a feature of Heroku called Heroku Flow. Heroku Flow, compared to Github Actions, is “more opinionated.” In other words, setting up Heroku Flow is easier to automate deployments in the particular way that Heroku Flow works, but Github Actions has the possibility to be more customizable and deviate from the way Heroku Flow works. However, in my opinion, Heroku Flow is likely to work for the vast majority of CI/CD workflows.

To set up the basics of Heroku Flow to deploy apps directly from a GitHub repo, follow these steps:

Set up a Github repo for the code for the app.
Log into the app on Heroku and go to the Deploy tab.
On the Deploy tab, you’ll see under the Deployment method area an option to ‘Connect to Github’. This is how we’ll get Heroku talking to the Github repo for the app.
Click on ‘Connect to Github’ and authorize Heroku to connect with your Github credentials.
After authorizing Heroku to Github, search for the repository you want to connect to and hit the ‘Connect’ button.

Connect to Github

After connecting to the desired Github repo, the ‘Automatic deploys’ and ‘Manual deploy’ sections of the page become available.
Under the ‘Automatic deploys’ area, select the branch to deploy (typically master or Production) and then hit the ‘Enable Automatic Deploys’ button. If you have any tests as part of your CI process (and you should), you can check the ‘Wait for CI to pass before’ checkbox to instruct Automatic deploys to wait for the CI tests to pass before allowing each automatic deploy.

Automatic Deploys

After this last step, all of the approved commits and pull requests that merge into the selected branch will automatically deploy to the Heroku app. Viola! One piece of the DevOps lifecycle automated.

If for some reason, a manual deploy is necessary, go to the ‘Manual deploy’ area and manually deploy a branch from the repository.

Creating a ‘Deploy to Heroku’ Button on Github

In addition to the Heroku Flow automated deployments, we can also add a handy ‘Deploy to Heroku’ button to our Github repository to allow deployments to Heroku directly from the Github repository. This allows anyone with access to the repo to quickly deploy the app to Heroku with a click of a button!

There are few prerequisites to set up before we get our button working.

First we need an app.json file that contains descriptions and attributes of our app and optionally all of the ‘atoms’ of the application. If you do add atoms to the app.json file, then these atoms will be automatically created when the button is invoked—a very handy feature.

An app.json file might look something like this:

{
  "name": "Node.js Sample",
  "description": "A barebones Node.js app using Express",
  "repository": "https://github.com/heroku/node-js-getting-started",
  "logo": "https://node-js-sample.herokuapp.com/node.png",
  "keywords": ["node", "express", "static"]
}

Once we have the app.json file set up, the next step is to render the button itself. The button can be rendered using an implicit template markdown or raw HTML. The implicit template is handy for embedding the button in the readme section of the Github repo. Use the HTML version if you’re rendering the button somewhere else like on a web page for the app. The implicit template is a bit more convenient because it can use the referrer header from the repo when someone clicks on the button from Github and avoids hard-coding the specific repository URL into the button. This allows forks and branches of the repository to work properly without a change to the button href URL itself. You can also add URL parameters to the buttons.

An example of an implicit template with URL parameters:

[![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://heroku.com/deploy?template=https://github.com/heroku/node-js-getting-started)

An example of the HTML version with URL parameters:

<a href="https://heroku.com/deploy?template=https://github.com/heroku/node-js-getting-started">
  <img src="https://www.herokucdn.com/deploy/button.svg" alt="Deploy">
</a>

After adding the button code to the readme file in the repo or to the website, clicking on the button will automatically take you to the ‘deploy app’ menu in Heroku and you’re off to the races deploying the app to Heroku.

Another powerful feature of the ‘Deploy to Heroku’ button method is the ability to add and pre-fill different environment variables and create variations of your Heroku app deployment by populating different environment variables that you have set up for your app.

Heroku Pipelines

A common requirement for DevOps is to have a single app living on multiple separate environments such as one for staging and one for production. To fulfill and automate this use case, we can use Heroku Pipelines. To get started creating a new pipeline, from the main menu in Heroku, select the ‘New’ dropdown and select ‘Create new pipeline’.

Then we will need to fill out the information for our new pipeline and connect it to a Github repo.

Create new pipeline

Once we hit ‘Create pipeline’ we can start setting up the pipeline.

From here, we can add our app to the Staging step of our pipeline and connect our Github repo’s staging branch and also set up automatic deployments as we did earlier. This makes it so that each commit/merged pull request to that branch will automatically deploy to the staging app on our pipeline. We can then connect the live branch of our app to the Production step of the pipeline but NOT enable automatic deployments. The whole point is that we want to first validate that everything is working in the staging environment before going ahead and promoting to production.

Finally, the ‘Enable Review Apps’ functionality is very useful for creating a test app each time a pull request is created against the branch. Setting up and enabling Review Apps on Heroku this way will allow you to conveniently create a test app for the pull request so that you and any reviewers of the pull request can test out the new features and perform any manual regression tests needed before approving the pull request. Then, once the pull request is merged into a branch that has been set up with Automatic Deployments, it will get automatically deployed to the next step of our pipeline.

And with that, some really nice automation has been added to our app’s DevOps processes so that the developers have ‘easy buttons’ that do the heavy lifting on some of these repetitive tasks allowing the developers to focus on the build aspects of the app!

Concluding Thoughts

For Salesforce admins and developers, I think that the ease of configuration and adding new functionality to the Salesforce application has gotten us somewhat ‘spoiled’ versus a more traditional DevOps process. As a result, I have noticed some resistance in adopting a more defined DevOps process because, in the beginning, it has a tendency to slow things down for the admins and developers who might be used to quickly deploying new features and changes from sandbox to production or even making the changes in the production environment itself.

However, the Salesforce or Heroku app will eventually increase in size and scope and eventually outgrow the simple processes in place when it was just one or two people working on it. And before that happens, you’re going to want to set up a sustainable and future-proofed application lifecycle management process or struggle with every single release trying to manage all of the steps of the process and its dependencies manually.

And since this is the last article of this series, I want to thank everyone for reading my content and following me along in this journey in learning more about modern application development on the Salesforce and Heroku ecosystems!

For more information, Trailhead modules, and advanced topics related to Salesforce and Heroku app deployment and packaging, check out the links to the resources below:

If you haven’t already joined the official Chatter group for this series, I certainly recommend doing so. This will give you the full value of the experience; in the group, you can also pose questions and start discussions with other members. There are often valuable discussions and additional references available, such as presentation slides and other resources and references.

https://sforce.co/34Ld7xz

About me: I’m an 11x certified Salesforce professional who’s been running my own Salesforce consultancy for several years. If you’re curious about my backstory on accidentally turning into a developer and even competing on stage on a quiz show at one of the Salesforce conventions, you can read this article I wrote for the Salesforce blog a few years ago.

Deploying Salesforce and Heroku Apps with Ease

Jason Sun — Fri, 26 Feb 2021 21:58:45 +0000

(Heroku and Salesforce - From Idea to App, Part 12)

This is the 12th article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”). eCars allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Automating Business Processes Using Salesforce Flows and APEX

Scale Salesforce Apps Using Microservices on Heroku

More Scaling Salesforce Apps Using Heroku Microservices

Javascript Unit Testing

APEX Unit Testing on Salesforce

Just as a quick reminder: I’ve been following this Trailhead Live video series to brush up and stay current on the latest app development trends on these platforms that are key for my career and business. I’ll be sharing each step for building the app, what I’ve learned, and my thoughts from each session. These series reviews are both for my own edification as well as for others who might benefit from this content.

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

Last time, we went through unit testing of Salesforce Apex code and learned about the unique unit testing framework that the Salesforce platform provides.

Now that we’ve built all the pieces of our eCars app, it’s time to move onto the exciting part: deploying the app so it can be accessed and enjoyed by our end users! We’ll cover packaging and deployments for both JavaScript as well as Salesforce apps.

Creating JavaScript Packages with npm

We’re going to start off with how to create packages for our Javascript application using npm. It’s important to know that npm is the JavaScript package registry—where all of the Node.js and JavaScript packages live. It’s basically the world’s biggest vault of useful app development libraries, utilities and other useful things you might need to import to your project in order to generate charts, render PDFs, or create 3D graphics. Everything on npm is open-source, so you and other developers are actively contributing to the open-source ecosystem when packaging with npm.

To get started with npm, you’ll have to first register for an account at https://npmjs.com/signup. Enabling two-factor authentication is highly recommended for your npm account. There have been some nightmare stories in the past where some people’s npm accounts have become compromised and bad actors were able to publish versions of their packages with malicious code in it!

Once you have npm up and running, from the command line, you can execute a few steps to start preparing your npm package.

1.     Create a package.json file by running `'npm init' `from the VS Code terminal

The package.json file contains all the metadata for your app such as the name, the components, dependencies, etc. The above command will take you to a wizard-like process in the command line to fill out some information to generate your package.json file.

2.     Add any secret files to the `.npmignore `file

This file is similar to .gitignore or .forceignore and will prevent any specified files from being published to the public npm registry. Any files that contain secrets, keys, or other sensitive information should be added to the file so they aren’t exposed to the public.

3.     Preview the package with the `'npm pack'` command to view what is going to be published

This is a good way to check if there are any files you need to add to the .npmignore file in step 2.

4.     Login with `'npm login'`  if you are not already logged in and use `'npm publish'`   to publish the package and watch the magic happen

At some point, you’ll likely want to update your package, make improvements, fix bugs, or otherwise push an update to your package. This process is pretty simple and after making your needed updates, you can push them out with the following process:

1.     Run `'npm version patch/minor/major'` to bump your package to another version


2.     Run `'npm publish'` again to publish your new package version

When versioning your packages, you should follow the “Semantic Versioning” or semver nomenclature with a format that resembles 2.0.1 or MAJOR.MINOR.PATCH. Generally, this means the following:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backward-compatible manner,
PATCH version when you make backward-compatible bug fixes.

Semver isn’t just for npm or JavaScript packages; it should be followed for any kind of app package versioning including unmanaged and managed Salesforce packages.

For more about semver, check out this link: https://semver.org/

Types of npm Packages and Naming Guidelines

There are three major types of npm packages, each with some distinct features and use cases.

Unscoped Public Packages

Available to all users
Have unique names
Examples:
- Express
- Fastify
- Moment

These are the common global, public packages that you will frequently come across when it comes to importing a particular package for your app.

Scoped Public Packages

Available to all users
Are published under a scoped namespace
Require an npm organization
Must have a unique name
Examples:
- @lwc/engine
- @lwc/compiler
- @heroku/foreman

These are often forked versions of unscoped public packages that may have some unique modifications to them to suit a particular use. They’re scoped in their own namespace so as to be isolated from the unscoped public packages.

Private Packages

Available to users of a paid npm enterprise organization
Can be org scoped, user scoped, or have no scope

Private packages are used when an organization wants all the benefits of npm but is developing packages that will not be published in the public npm registry. These could be home-grown apps that are only used for a particular organization.

Now that we know about the different types of packages, let’s go over some package naming guidelines. In general, package names should abide by the following guidelines:

Names are unique
Names are descriptive
Names meet npm name policy guidelines and do not use offensive or trademarked words

In case you’re choosing a name for an unscoped package, you should also:

Choose a name that is not already owned by someone else
Not be spelled in a similar way to another package (so as to avoid confusion)
Not confuse others about the authorship of the package

Follow the guidelines above and you’ll avoid receiving any nasty letters from law firms!

Salesforce Development Models and Packaging

When I was starting out as a Salesforce administrator, the concepts of “deployment” and “packaging” did not come up very often. I was usually configuring things using point-and-click methods directly in the production environment (gasp!). Every now and then, I might deploy an APEX class or trigger from a sandbox environment to the production environment using the Changesets tool. That was because admins had to deploy those types of custom code from a sandbox at that time in order to get them into production. As a result, most Salesforce administrators may be more familiar with the aforementioned process of customizing the org itself. This is referred to as “org development” or “unpackaged” development. The other possible development model is “package development,” which you may only come across if you have created unmanaged, managed, or unlocked packages— perhaps in the course of creating a Salesforce app for distribution on the AppExchange.

The key for each development model is in the “source of truth” for the application. In org development—the one Salesforce folks are likely most familiar with—the org itself is the source of truth. That’s different from package development, where the source of truth is typically a git repository for the application’s code and metadata.

When comparing to JavaScript app packaging, think of org development as a private package for use with that specific Salesforce org. Meanwhile, package development is more like creating a public package that’s intended for public use in other Salesforce orgs.

Let’s say that you or your company want to become a Salesforce ISV and go for package development. It’s then important to know all about Salesforce packaging and requirements.

In general, Salesforce packages:

Represent a container of metadata. This includes all customizations and custom code
Must compile and validate in order to deploy to other orgs
Usually require you to map a package to a directory in the project workspace (when packaging with Salesforce DX Source format)

One obvious advantage of unpackaged/org development on Salesforce is that it’s fast and gives you immediate gratification. In other words, the org that’s being used gets to realize the benefits of the development changes immediately. However, it’s important to also realize how beneficial package development can be, despite having more steps and creating some overhead tasks.

Some benefits of package-based development

In addition to the benefits shown above, I would also argue that package development forces Salesforce admins and developers to adopt a sense of discipline when it comes to being organized and planning for the future maintenance, scalability, and iterability of the application. Unpackaged development, while fast, can end up creating a great deal of technical debt that eventually has to be paid back once the org becomes difficult to maintain and manage.

There are different types of Salesforce packages as well.

Managed Packages – These are the types of packages that are geared towards Salesforce ISV partners and publishers of apps on the AppExchange. With 2GP managed packages, the ISVs also get additional features like push upgrades and access to the License Management tool.

Unlocked Packages – Unlocked packages are primarily used to address the packaging needs of individual customers and their Salesforce orgs. This is the ideal fit for those Salesforce orgs that are not going to publish to the AppExchange but want to adopt a package-based approach for the benefits mentioned above.

Under the category of Unlocked Packages, there are two subtypes also.

Org Independent – Org independent packages are packages that don’t have dependencies on the org itself. They can support multiple different orgs while still maintaining the core business process and functionality. Dependencies are validated during package creation and dependencies on other packages can be set.

Org Dependent (Runtime Packages) – Org dependent packages might be used for massive orgs where untangling the dependencies may not be an option. The dependencies are validated during package installation instead of at package creation and can depend on other packages as well as the target org itself. It’s recommended to use sandboxes with a source tracking tool with these packages.

Creating a Salesforce Package in VS Code

When working with SalesforceDX and VS Code, an sfdx-project.json file is created automatically that contains some packaging information for the app. This is just like the package.json file we have for JavaScript applications deployed on npm. Note that you can add a “namespace” to the file. Doing so will add a namespace prefix to all of the components in the package such as custom fields, objects, APEX classes, etc. This step will ensure that the package components will not collide with metadata in target installation orgs. It will also make the package components easy to spot and identify once they are installed.

After the app is ready to be packaged, running the following command on the command line will initialize the Salesforce package and update the sfdx-project.json file.

sfdx force:package:create -n [name of the package] -t [type of package] -r [directory of package]

The sfdx-project.json file after running the force📦create command

As you can see, we have the first version of the package initialized. In this step, a package ID gets generated. Next, if we wanted to bump a version of the app, we would use the following comment.

force:package:version:create - p [package id] -x/-k [optional password]

Note that the -k with optional password attribute will lock the package with a specific password, whereas using the -x parameter indicates that there is no password and that this will be more of an open-source project.

This particular command/process takes some time to complete because it’s actually creating a scratch org, compiling all of the metadata, checking dependencies, and running all APEX tests to make sure that everything validates. Once it does though, you’ll have a beautiful and updated sfdx-project.json file with all of the correct package information!

Packaged and gift-wrapped eCar application

The installation URL is where people will go to actually install the package into their respective orgs. Now, we can offer the eCars app to Salesforce orgs across the entire ecosystem!

Concluding Thoughts

As mentioned earlier, Salesforce admins and developers may not naturally approach things from a package-based development perspective. However, the whole concept of organizing code and metadata and their respective dependencies into a neat and cohesive container can pay dividends. Those payoffs exist even if the organization is not planning to publish their solution on the AppExchange. This is super relevant, especially for orgs that grow in size and complexity. Adopting a package-based approach as soon as things start getting complicated will ensure that the discipline inherent in package-based development will keep the org scalable, maintainable, and manageable. I have seen many orgs bury themselves beneath a mountain of technical debt that has resulted from undisciplined development and configuration. Hopefully, more members of the Salesforce ecosystem will start adopting package-based development with Unlocked Packages!

For more information, Trailhead modules, and advanced topics related to Salesforce and Heroku app deployment and packaging, check out the links to the resources below:

In the next article, we’ll go through the final topic in the series: managing the app development lifecycle and automating developer workflows.

https://sforce.co/34Ld7xz

Apex Unit Testing on Salesforce

Jason Sun — Fri, 26 Feb 2021 21:28:39 +0000

(Heroku and Salesforce - From Idea to App, Part 11)

This is the eleventh article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Automating Business Processes Using Salesforce Flows and APEX

Scale Salesforce Apps Using Microservices on Heroku

More Scaling Salesforce Apps Using Heroku Microservices

Javascript Unit Testing

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

Last time we explored unit testing with Javascript and jest. This time we are focusing on unit testing again but for the Salesforce platform.

For some, automated unit testing is an essential part of the application development process and a key component to making sure that code is running and behaving as expected. For some (and I’ve been guilty of this in the past), unit tests in Salesforce is that annoying gatekeeper that stops me from deploying my custom APEX code until I’ve satisfied the 75% code coverage requirement. Hopefully, after this session, we can change the perception of unit tests as a tool that greatly helps with our application development and maintenance processes as opposed to some kind of adversary.

A Primer on Unit Testing

What is “unit testing” exactly and what’s different about unit testing versus other testing methods like regression testing or smoke testing?

The “unit” part refers to the fact that the testing is verifying that a discrete method in the code, functionality or automation is working as intended separately from other dependencies. So if you have a trigger handler with several methods, you might write unit tests that target those specific individual methods as opposed to testing the entire class.
The “testing” part is self-explanatory and just refers to the fact that you’re making sure that the method in code, functionality, or automation is working as expected.

Unit tests in a nutshell

Here are some valuable benefits of unit tests:

Identify bugs easily and detect them earlier
Reduces the cost of fixing bugs and QA efforts
Makes code design and refactoring easier
Acts as a self-documenting set of test cases

However, these benefits are only fully realized when unit testing is implemented correctly and thoughtfully. Oftentimes, I come across cases where unit testing has been implemented as an afterthought, only implemented with the bare minimum requirements to actually deploy the code, or in some of the worst-offending cases, completing cheating the process.

A Framework for Unit Testing

The framework we’re basing our unit test design here is the “AAA” or Arrange, Act, and Assert framework. This framework doesn’t just apply to Salesforce code but can be used with any programming framework that supports unit tests.

The Salesforce examples for these would be something like as follows:

Arrange: Test data setup and inserting the objects/records needed for the unit test
Act: Call your methods or perform DML statements to run the code you want to test and capture the result
Assert: Create assert statements comparing the results you captured with expected results. You typically want the test to error out or notify you in some way if the result you captured deviates from the expected result.

Unit testing is a core part of the Salesforce platform and Salesforce actually has specific requirements around unit tests and code coverage for deploying custom code to a production environment. Some Salesforce-specific rules about testing are as follows:

Here are several additional details on the above bullet points as well.

It’s nice that Salesforce actually uses its customers’ unit tests to help run regressions before each of their major releases since Salesforce instances can be highly customized with APEX code. A release breaking my existing code has been exceedingly rare and a nice feature of APEX classes is that you can actually set the API versions of them to be on a prior Salesforce release and then only upgrade them to the latest version when you have also fully tested things on your own.

This 75% code coverage requirement means that if you have 1000 lines of APEX code across the entire org, APEX test classes must simulate and run at least 750 of those lines of code in order for code updates or new code to be deployed. This is where I’ve seen some pretty clever workarounds (read: cheats) that I won’t share, but just know that they should never be used and you should always strive to write legitimate and well-thought-out unit tests.

Having a variety of test cases makes the unit tests much more valuable since you are covering more edge cases with them. As a result, they can alert you if some change to the system is introduced that impacts the code from performing as expected.

Positive tests - is the code doing the right thing when it’s supposed to?
Negative tests - is the code not doing the thing when it’s NOT supposed to?
Bulk tests - does the code still run as expected if a large chunk of records updates at once? Or do we hit some kind of CPU time-out error or SOQL query limit error?
Profile/permission tests - does the code run as expected when performed by users with different profiles and permissions? Or is there some dependency created when a different profile tries to run it?

Finally, having a “Datafactory” class is a huge time-saver because having one place where valid test data can be generated and called by other test classes will come in handy. For example, adding a new required field or validation to the system often causes unit tests to break because the test data does not account for the new field or validation rule. Having a single place where you can update this saves you the trouble of having to change the test data setup for each of your affected unit test classes.

Creating an Apex Unit Test for the eCars App

For the eCars app that we’re building, the activity will be to write an APEX test class for the PdfCreateService that we used in the prior session to call a Heroku microservice for generating PDF documents. The eCars code can be found at the linked Github repo and I have also included a link to the specific PdfCreateService class. If you have not gone through the exercise of pulling the code into a Salesforce Developer org or a scratch org, you’ll want to review some of the previous articles to take that pre-requisite step or follow the instructions in the Github repo on how to clone and deploy the application.

You’ll see when examining the PdfCreateService class, it’s a pretty simple class with really one method, invokePdfCreateService, which takes a single parameter of a custom child class called ServiceInput and then makes an outbound HTTP callout to an external Heroku service. The ServiceInput child class is also used to conveniently serialize JSON data for the Heroku service.

public with sharing class PdfCreateService {
    @AuraEnabled
    public static Boolean invokePdfCreateService(ServiceInput input) {
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:Heroku_App/pdf');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json;charset=UTF-8');
        req.setTimeout(30000);
        req.setBody(JSON.serialize(input));


        Http http = new Http();
        HttpResponse res = http.send(req);


        if (res.getStatusCode() != 200) {
        String error =
            'The status code returned was not expected: ' +
            res.getStatusCode() +
            ' ' +
            res.getStatus();
        AuraHandledException e = new AuraHandledException(error);
        e.setMessage(error);
        throw e;
        }


        return true;
    }


    @testVisible
    class ServiceInput {
        @AuraEnabled
        public String exteriorColor { get; set; }
        @AuraEnabled
        public String interiorColor { get; set; }
        @AuraEnabled
        public String range { get; set; }
        @AuraEnabled
        public Decimal price { get; set; }
        @AuraEnabled
        public Id leadRecordId { get; set; }
    }
}

The first step of creating the unit test is to create a testDataFactory class to help generate the test data for the unit test. This isn’t included in the Github repo as of today, so you’ll need to write one yourself, follow along in the video to create one, or grab it from the solutions sheet that is posted in the Chatter discussion group linked at the end of this article. The testDataFactory class will need to be able to create a test Lead, a test User, and also assign the test User the necessary permission set for the eCars app.

We chose a bit of an interesting class to unit test because this class has a method that makes a webservice callout to an external service. It would be quite a problem if our unit test actually made a real webservice callout to the external service for two major reasons. First, how would the external service know that it’s just a test and not a real callout and behave accordingly? Second, we don’t know how the real external service might behave at any given moment like for example if there is service disruption and it’s down exactly when we are running our tests.

As a result, Salesforce provides a way to actually create something called an HTTPMock class that is specifically used for testing methods that make web service callouts so that the expected behavior from the web service can be simulated or “mocked” in the HTTPMock class specifically for unit testing use cases. There’s a specific interface called HttpCalloutMock that needs to be implemented as shown below.

global class YourHttpCalloutMockImpl implements HttpCalloutMock {
global HTTPResponse respond(HTTPRequest req) {
    // Create a fake response.
    // Set response values, and
    // return HTTPResponse object
}
}

The goal for the eCars app would be to create a PdfCreateServiceMock class that we can use in our test classes to return a variety of HTTP responses and payloads. In the video, Mohith provides an example of this but you should try to create your own version that might handle a number of other cases and responses.

More information on testing HTTP callout methods and code samples can be found at the APEX Developer Guide as well as the APEX recipes Github repo.

The last step, once we have our testDataFactory class and PdfCreateServiceMock class, is to create the actual TestPdfCreateService test class that will utilize both of the prior classes. The test class should:

Create test data using our testDataFactory class, including one or more test users with different relevant profiles, as well as one or more test Lead records for running our test with
Assign permission sets to the user(s)
Have one or more test methods that run as our test users using the system.runAs method
Set data for the PdfCreateService.ServiceInput child class
Invoke the PdfCreateService.invokePdfCreateService with the ServiceInput object set previously
Call the PdfCreateServiceMock with the desired mocked up response
Run system.Assert statements to assert that the results from running the code match up to our expected results

If all of the above criteria are fulfilled, once you run your test class using VSCode’s handy “runTest” command (comes with the Salesforce tools VSCode extension), you should get something like 90%+ test coverage. Inspecting the classes in VSCode or the developer console will show which lines of code were covered in the test run vs. which ones were not.

If you weren’t able to get your test class built and solved on your own, that’s fine. A solution for this should be posted in the Chatter discussion forum or you can ask for help there if you are stuck.

Unit Testing in APEX vs. Javascript

For those who are familiar with testing in Javascript but not in APEX or vice-versa, here are some key things to note. The Apex language comes with system methods for writing apex unit tests classes. For JavaScript, there are a number of different testing frameworks but Salesforce recommends using Jest for Lightning Web Components and LWC OSS because of its popularity, ease-of-use, and open-source framework. Jest for Lightning Web Components is available at the sfdx-lwc-jest Github repo. The following table draws some comparisons between the frameworks.

Concluding Thoughts

As mentioned early on, unit testing in my opinion is one of the most underutilized and underappreciated components of building apps on the Salesforce platform. I often see a great deal of technical debt that is built up that revolves around unit tests and APEX test classes. It’s gotten to the point where if I’m jumping into a project where some coding has already been done, the first thing I do is run all of the org’s APEX test classes and see how many of the unit tests fail or provide insufficient coverage to certain classes. I think this happens because too many people approach unit tests as a kind of barrier or box that you just have to check in order to get your code to deploy, but it doesn’t have to be this way. If more developers approached unit tests as a helpful and core part of the code that they’re developing, well-built and designed unit tests can actually end up saving on technical debt.

For more information and advanced topics related to unit testing, check out the links to the resources below:

In the next article, we’re going to go through the application package and deployments.

If you haven’t already joined the official Chatter group for this series, I certainly recommend you do so. That way, you can get the full value of the experience and also pose questions and start discussions with the group. Oftentimes, there are valuable discussions and additional references available there such as the slides from the presentation and links to other resources and references.

https://sforce.co/34Ld7xz

Javascript Unit Testing

Jason Sun — Tue, 16 Feb 2021 17:26:41 +0000

(Heroku and Salesforce - From Idea to App, Part 10)

This is the 10th article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Automating Business Processes Using Salesforce Flows and APEX

Scale Salesforce Apps Using Microservices on Heroku

More Scaling Salesforce Apps Using Heroku Microservices

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

Last time we dove deeper into connecting services and apps hosted on Heroku with Salesforce to provide real-time notifications and IoT data to Salesforce as well as how to scale these services for massive throughput needs. This time we’re looking at automated ways to verify that our Javascript apps and services code are running correctly. Specifically, we are going to learn about Javascript Unit Testing.

Automated unit testing is an important part of the application development process and a key component to making sure that code is running and behaving as expected. Unlike with Salesforce APEX code, which requires at least 75% overall code coverage of triggers and classes, Javascript apps don’t explicitly require unit tests, but it is simply good development practice to have unit tests as part of the process. Applications that try to cut corners on this aspect of the application development lifestyle end up paying the price in the form of discovering more expensive bugs during regression testing or worse, shipping apps with bugs to customers and end-users.

A Primer on Unit Testing

What is “unit testing” exactly and what’s different about unit testing versus another testing methodology like regression testing or smoke testing?

The “unit” part refers to verifying that a discrete method in the code, functionality, or automation is working as intended separately from other dependencies. So, in Javascript, if you have a particular function that is supposed to take some arguments, process them, then fire a callback, you might write unit tests that target that specific function as opposed to testing the entire class.
The “testing” part simply refers to ensuring the method in code, functionality or automation is working as expected.

Unit tests in a nutshell

Here are some examples of how unit tests can be valuable:

Identify bugs easily and earlier
Reduce costs related to fixing bugs and QA efforts
Facilitate code design and refactoring
Self-documents sets of test cases

However, these benefits are only fully realized after implementing unit testing thoughtfully and correctly. This process is often implemented poorly or skipped entirely.

A Framework for Unit Testing

Regardless of the programming language, we’re using, a good framework to base our unit test design is the Arrange, Act, and Assert (AAA) framework.

A good thing to remember with unit testing is that you are managing the “expectations” or “specifications” of the code with unit tests. This means the unit tests have something to say about code specs and what the expectations are for the code when it runs. In some cases, I’ve heard of development methods that involve writing the unit tests _first, _and then developing the actual code later since the unit tests can act as documentation for how the code should behave.

Some Javascript examples for can include:

Arrange: Test data setup and inserting the necessary objects/records for the unit test
Act: Call your methods/functions or otherwise run the code you want to test and capture the result
Assert: Create assertion statements in your unit test and compare the results you captured with expected results. You want the test to error out or notify you in some way if the result you captured deviates from the expected result.

Jest – Testing Tool for Javascript and LWC

Javascript has a number of different testing libraries and frameworks available, but we’re focusing on one in particular: Jest. This is the recommended testing framework for Salesforce Lightning Web Components (LWC) because of its ease-of-use, open-source nature, and popularity. Specifically for LWC, Salesforce has a wrapper library on top of Jest called “sfdc-lwc-jest” which can be found at the following Github repo.

https://github.com/salesforce/sfdx-lwc-jest

Also if you’re using Visual Studio Code (VS Code) with LWC (and you should), you will also want to install the following extension packs for VS Code.

Unit Testing for the eCars App

The Javascript LWC apps and microservices hosted on the Heroku side of our app have a decent number of client-side interactions through the UI. Specifically, we are going to test the Car Configurator app. It makes sense to apply unit testing to our app so that when we make enhancements and additions to the code, our unit tests can help us catch issues with the app.

So many buttons and interactions, so many ways errors can happen

The Javascript car configurator app we are going to test can be found on the eCars app Github repository. If you’ve been following along with this series, then you should have already done some previous setup work installing the repo in VS Code and deploying it to a Salesforce scratch org.

If you look at the .html and .js file in the carConfigurator LWC, you’ll see that the HTML has some expected behavior and bindings to variables in the .js file. For our tests, we’re going to test that the LWC renders the expected components and values to the DOM as the test progresses. We’ll soon look at how Jest and the sfdc-lwc-jest wrapper library makes this magic happen.

First, we will need to create a testing scaffold for our unit tests with the following command in VS Code:

sfdx force:lightning:lwc:test:create -f [file path]

If the command runs successfully, your terminal should look something like this:

This creates a carConfigurator.test.js test scaffold file that we can use to build our tests. There should be a pre-built stub for the functions in the test file that you would expand upon as you build out your tests.

When you initialize your LWC project in VS Code and take a look at the package.json file, you’ll see that there are some lwc-dependencies and scripts that are included in the package. These scripts help make some of the lwc-jest magic happen.

Some lwc-jest dependencies called out in the package.json file

Unit Tests Code in Detail

There’s a lot to unpack if you’re like me and have never done Javascript unit testing or worked with the Jest library before. So, we will skip ahead to the fully built-out solution that is used in the demo and pick out some important things to note. Here’s the fully completed carConfigurator.test.js code below. In each of the test methods, you can get an idea of what the unit tests are testing for by looking at the name/description right after the it() function declaration. We’ll review some of the important highlights in this test script after you’ve scrolled through.

import { createElement } from "lwc";
import CarConfigurator from "c/carConfigurator";
import CURRENCY from "@salesforce/i18n/currency";
import invokePdfCreateService from "@salesforce/apex/PdfCreateService.invokePdfCreateService";

jest.mock(
  "@salesforce/apex/PdfCreateService.invokePdfCreateService",
  () => {
return {
      default: jest.fn(),
};
  },
  { virtual: true }
);

describe("c-car-configurator", () => {
  afterEach(() => {
while (document.body.firstChild) {
      document.body.removeChild(document.body.firstChild);
}
  });

  // Helper function to wait until the microtask queue is empty. This is needed for promise
  // timing when calling imperative Apex.
  function flushPromises() {
// eslint-disable-next-line no-undef
return new Promise((resolve) => setImmediate(resolve));
  }

  it("renders section 1 with image", () => {
const element = createElement("c-car-configurator", {
  is: CarConfigurator,
});
    document.body.appendChild(element);
const imageDiv = element.shadowRoot.querySelector("img");
const rangeAnchors = element.shadowRoot.querySelectorAll("a");
const formattedNumbers = element.shadowRoot.querySelectorAll(
      "lightning-formatted-number"
);
return Promise.resolve().then(() => {
      expect(imageDiv).not.toBeNull();
      expect(imageDiv.src).toBe(
        "https://sfdc-demo.s3-us-west-1.amazonaws.com/ecars/car_white.jpg"
  );
  expect(rangeAnchors.length).toBe(3);
      expect(rangeAnchors[0].dataset.range).toBe("Short Range");
      expect(rangeAnchors[1].dataset.range).toBe("Medium Range");
      expect(rangeAnchors[2].dataset.range).toBe("Long Range");
  expect(formattedNumbers.length).toBe(3);
      expect(formattedNumbers[0].currencyCode).toBe(CURRENCY);
      expect(formattedNumbers[0].value).toBe(25000);
      expect(formattedNumbers[1].value).toBe(35000);
      expect(formattedNumbers[2].value).toBe(45000);
});
  });

  it("navigates to different section on next button click", () => {
const element = createElement("c-car-configurator", {
  is: CarConfigurator,
});
    document.body.appendChild(element);
const button = element.shadowRoot.querySelector("lightning-button");
    button.click();
return Promise.resolve().then(() => {
  const exteriorColorAnchors = element.shadowRoot.querySelectorAll("a");
      expect(exteriorColorAnchors.length).toBe(5);
  expect(exteriorColorAnchors[0].dataset.color).toBe("white");
      expect(exteriorColorAnchors[1].dataset.color).toBe("black");
      expect(exteriorColorAnchors[2].dataset.color).toBe("red");
      expect(exteriorColorAnchors[3].dataset.color).toBe("blue");
      expect(exteriorColorAnchors[4].dataset.color).toBe("green");
});
  });

  it("invokes pdf processing service", () => {
    invokePdfCreateService.mockResolvedValue(true);
const LEADID = "00Q9A000001TNllUAG";
const INPUT_PARAMETERS = {
  price: 25000,
  range: "Short Range",
      exteriorColor: "Pearl White",
      interiorColor: "Vegan White",
      leadRecordId: LEADID,
};

const element = createElement("c-car-configurator", {
  is: CarConfigurator,
});
document.body.appendChild(element);
const button = element.shadowRoot.querySelector("lightning-button");
    button.click();
const section2NextButton = element.shadowRoot.querySelector(".button-next");
    section2NextButton.click();
const section3NextButton = element.shadowRoot.querySelector(".button-next");
    section3NextButton.click();
return flushPromises().then(() => {
  const recordEditFormElement = element.shadowRoot.querySelector(
        "lightning-record-edit-form"
  );
      expect(recordEditFormElement).not.toBeNull();
  const inputFieldElement = element.shadowRoot.querySelector(
        "lightning-input-field"
  );
      inputFieldElement.value = LEADID;
      expect(inputFieldElement).not.toBeNull();
      inputFieldElement.dispatchEvent(new CustomEvent("change"));
  const section4NextButton = element.shadowRoot.querySelector(
        ".button-next"
  );
      section4NextButton.click();
      expect(invokePdfCreateService.mock.calls.length).toBe(1);
      expect(invokePdfCreateService.mock.calls[0][0]).toEqual({
        input: INPUT_PARAMETERS,
  });
});
  });
});

Import declarations are importing some of the required dependencies for running our tests. Note that you can’t use the createElement in LWC code, but you can for the unit test file.

Jest.mock is an interface that reminds me of the HTTPCalloutMock interface from Salesforce unit testing. Jest.mock mocks calls and responses to external services. In the context of our test, we can’t _actually _make an imperative call to our PdfCreateService APEX class/methods so we have to mock this call and response.

It’s important to note that this could be a point of failure in our tests because what we mock up could be different than how the actual PdfCreateService method behaves. Therefore, it’s a good idea to have a unit test on the Salesforce side that verifies that the PdfCreateService class is behaving correctly. This is actually exactly what we will do in the next session.

A DOM reset is needed after each unit test because the same jsdom instance is shared across all unit tests in the file. The code snippet below ensures that we’re working with a clean slate after each unit test so that we’re not getting erroneous test results due to leftovers in the jsdom after the previous unit test.

describe("c-car-configurator", () => {
  afterEach(() => {
while (document.body.firstChild) {
      document.body.removeChild(document.body.firstChild);
}
  });

The flushPromises code snippet below helps us handle callbacks and making sure that each callback resolves properly with a Promise.

  function flushPromises() {
// eslint-disable-next-line no-undef
return new Promise((resolve) => setImmediate(resolve));
  }

The unit tests themselves now make up the remainder of the test file. There is a lot of material to unpack in each specific unit test in terms of how to set- p the test and invoke what needs to be tested, so we’ll have some homework to do at the end of this article. However, each individual unit test will have a general form that follows something like the code below:

  it("A friendly label for your unit test", () => {
//Initialize your test case here
const element = createElement("c-component-name", {
  is: ComponentName,
});
document.body.appendChild(element);
//Then perform the actions that your test is seeking to test/simulate
const button = element.shadowRoot.querySelector("button-being-tested");
button.click();

//Resolve Promises
return Promise.resolve().then(() => {
  //Set a variable for the element you're inspecting
  const ElementToBeTested = element.shadowRoot.querySelectorAll("selectorForElementToBeTested");

//Make assertions with the expect() function and check if you're getting the correct desired result
Const ExpectedValue = "Expected value";
  expect(ElementToBeTested.property).toBe(ExpectedValue);
});
  });

As you can see, even though the specific code in each unit test varies, all tests follow the same pattern from our original AAA Framework. With this framework, pretty much any element in our app, including rendering behavior, navigation, button clicks, and service callouts can be unit tested to ensure that the code is working correctly!

Concluding Thoughts

I’m going, to be honest. From someone who came from a background of unit testing for Salesforce APEX code, the topics covered here were pretty foreign to me. I think the hardest part to grasp was the Jest methods used for testing UI behavior and rendering items. For example, “shadow DOM”, “root and child elements”, and other front-end heavy items were not things I typically worried about as a Salesforce administrator or developer.

However, I also recall a time when APEX unit testing was also a pretty foreign concept to me. But once I understood the purpose of unit testing and the syntax and methods used to set up and run the tests and create assert statements to verify that the code is running properly, things became much easier. I expect the same outcome with Javascript unit testing and learning how to use tools like Jest.

For more information and advanced topics related to Javascript and LWC unit testing, check out the links to the resources below:

In the next article, we will explore more unit testing but specifically for Salesforce and APEX code.

If you haven’t already joined the official Chatter group for this series, I certainly recommend you do so. You will get the full value of the experience, ask questions, and start discussions with the group. Oftentimes, there are valuable discussions and additional references available, such as presentation slides and links to other resources and references.

https://sforce.co/34Ld7xz

More Scaling Salesforce Apps Using Heroku Microservices

Jason Sun — Thu, 04 Feb 2021 19:13:00 +0000

(Heroku and Salesforce - From Idea to App, Part 9)

This is the ninth article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”). eCars allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Automating Business Processes Using Salesforce Flows and APEX

Scale Salesforce Apps Using Microservices on Heroku

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

Last time we explored connecting microservices hosted on Heroku with Salesforce to offload high-cost operations and processes. It turns out this topic is important enough to warrant a second video and article dedicated to the same subject!

This time we are going to cover some pretty cool Heroku features and integrations with Heroku apps including Progressive Web Apps (PWAs), using Kafka to scale MQTT protocols, and capturing change events in near real time.

In the very first video and article of the series, there were some previews of these potential use cases for these Heroku platform features, but now we’re going to see actual examples of their use and implementation!

As a reminder, the GitHub repo for this series and the eCars application used throughout is available at the following URL. There are a number of other sample apps in the overall repo as well.

https://github.com/trailheadapps/ecars

Architecture of the eCars Application

So far, the two major parts or “clouds'' of the application have been focused on Sales Cloud and Leads configuring their potential cars and now Service Cloud as well for certain customer service use cases. Both of the Salesforce clouds have external integrations. On the Sales Cloud side, we have a Progressive Web App (PWA) for the car configurator, a Heroku microservice for the handling of PDF generation, and a component for push notifications. On the Service Cloud side, we will have a streaming data Heroku app that leverages MQTT, Internet-of-Things (IoT), and Apache Kafka while integrating with Salesforce via web service APIs.

eCars Application Architecture

In this session we look at three demos, use cases, or integrations with Heroku apps and microservices:

A PWA car configurator that sends leads to Salesforce, manages push notifications, and crosses boundaries of native and web applications.
A real-time Heroku streaming data app that automatically opens a case and provides real-time IoT data from the car’s sensors that are reporting issues
Synchronizing data with Salesforce and an external data store for change data capture

Subscription and Push Notifications PWA Demo

First let’s look at the Heroku PWA that’s handling the car configurator and doing two things: Pushing a new lead to Salesforce Sales Cloud and subscribing that lead to notifications using the contact information they provide.

An example lead completing their car configuration and providing contact info

Once the user completes the information on this page, a lead is sent to Salesforce via the Salesforce REST API and the JSForce javascript library, which provides an abstraction layer for the Heroku app to make API calls to Salesforce.

Once the lead is in Salesforce, we can see that it’s possible for the salesperson to manually send out a web push notification back to the web application to the prospective buyer. This could also be invoked automatically using Salesforce’s automation tools such as Flows.

Sending the notification from Salesforce results in the web notification in the top right corner

In this architecture, we effectively have real-time notifications between Salesforce and the prospective user’s machine. This is possible with something called a “Service Worker” which is a kind of Javascript application that runs completely in the browser so that notifications can be received even when the web page isn’t open. I bet this is partially why my internet browser is so RAM-hungry?

Another very cool feature of PWAs is that they are not just web apps but can be installed and run from the desktop iOS or a mobile device and run like a native app providing the same experience, independent of the platform they run on! This is great because the PWA frees you from having to maintain separate codebases for your web app and your native mobile and desktop apps.

Finally, the PWA we see in the demo is actually built using Lightning Web Components so this wasn’t actually some specialized node.js app that’s far removed from the Salesforce ecosystem.

Under the Hood of the eCars PWA

Customer-facing PWA app architecture

Taking a look under the hood of the PWA App, there are a few components to explore. In the graphic above, we have in the boxes from left to right: the client’s browser, the Heroku server, and the Salesforce instance on the far right side.

Without diving too far into the weeds of the actual code (which you can just explore in the Github repo), here are some notable highlights:

The Heroku server is providing an HTTPS server via express to serve up the PWA app pages.
The Service Worker lives completely on the client’s browser to manage subscribes, push notifications, and communications with the HTTPS server.
The web-push library facilitates communication with the Service Worker and Salesforce APEX classes with web services callouts.
The service worker, running totally on a separate thread on the client’s browser provides some offline capabilities as well as pre- and run-time caching and background synchronization.

I have found that the Composite Graph API is potentially very useful on the Salesforce side. Typically when making inbound calls to create multiple related records via the Salesforce API, you have to make multiple API calls—one call to create the parent, another call to create child objects, and so on.) Then, you need to manage cases that involve rolling back the entire transaction thread because maybe the parent insert was successful but then only some of the child records inserted successfully while the rest errored-out. With the Graph API, you can make a single callout to string together otherwise separate calls and manage the success/failure of the entire composite call as one. This should really be the gold standard when it comes to operations that insert multiple records!

Real-Time IoT eCars Data Demo

In the next demo, we’re looking at a scenario that involves getting IoT data from the cars’ sensors and pipe the information to our app in real time. This will enable us to take some preemptive action on certain triggering events (a rapidly-draining battery in this case) and empower the service agents with that data.

An automatically opened case due to battery anomaly with real-time data accessible in the case view

So, we’re looking at a Salesforce service cloud case that was automatically opened because the IoT data received by our application from a particular car was not performing within expected thresholds. Then, in two of the tabs on the case, we can see lightning components that have battery diagnostic and real-time data streaming to the case for the service agents to access.

Imagine that we then combine this with Salesforce automation to send the owner of the vehicle a preemptive email notifying them that Pulsar is aware of the issue and are looking into it. We can also combine this with what we did in the PWA and send a push notification with the same content! This would take customer service and the experience of the Pulsar brand to a whole new level.

Under the Hood of Real-Time IoT eCars Data

So how do we get all this rich IoT data from the cars all the way back to Salesforce? Let’s take a look under the hood (pun intended) and see what kinds of components are making this magic happen.

Real-time service on Heroku

Here are some components to highlight below (Remember that all the code running behind these components can be found in eCars app Github repo)

MQTT Broker – This MQTT broker is a standalone application running on its own Heroku Dyno. MQTT is an extremely lightweight messaging protocol for IoT use cases. It’s a simple publish/subscribe messaging transport that is ideal for connecting remote devices with very little code and minimal network bandwidth. This MQTT broker is receiving data from the cars’ sensors and publishing them to clients that subscribe to the data. The specific MQTT library used for the eCars app is called Aedes and is a barebones MQTT server. More information is available on Aedes in the links at the end of the article.

eCars Real Time – The eCars real-time application is another standalone application running on its own dyno. As you can see, it comprises an events persistence module and an events connector module. The events persistence module handles taking the data from the MQTT Broker and persisting it to a sensor data database where it can be stored permanently and queried like a normal SQL database and perhaps stored in a data warehouse later. The events connector module also subscribes to the same MQTT Broker but has a different job—communicating with the Salesforce liveData LWC via a Raw Websockets API. This allows the service user on the Salesforce side to access the sensor data in real time.

Of course, the amount of data throughput can get pretty crazy as Pulsar sells cars and more of them are on the road all broadcasting sensor data. In order to scale this application, Apache Kafka comes into play. Apache Kafka is a distributed commit log for rapid, fault-resistant communication between producers and consumers using message-based topics and provides the backbone for building distributed applications capable of handling billions of events and millions of transactions.

Apache Kafka for when you need to handle massive throughput

With Apache Kafka added on, it helps the app increase real-time data throughput and allows other microservices to consume/subscribe to data without producing additional overhead. It’s not necessary to have Apache Kafka on your Heroku instance for the eCars app to function as it’s only needed for massive scaling use cases in production.

Data Synchronization with Change Data Capture

The final use case example is related to data synchronization and change data capture. This is similar to the previous “publish/subscribe” framework of the IoT example but can be applied to any use case where you might want to synchronize data between disparate applications or data stores.

Data synchronization with change data capture

The “event bus” is key to this architecture. It is where change data events are published to and can be subscribed from. This event bus is playing the same role as the MQTT Broker in the previous example. In our model above, the event is a vehicle changing status to “sold.” This update is committed to the database but also published to the event bus. This event bus can then serve up the change events to multiple subscribers.

In our eCars app, there is an LWC using the emp-API base component that subscribes to the events, however, a subscriber can also sit outside of the application and subscribe to the same event bus to then sync the data to an external database.

The main advantage of this model is that point-to-point integrations between multiple systems to keep the data in sync are no longer required. The event bus can serve as the singular hub for distributing this information.

Concluding Thoughts

The content in the demos covered for the eCars app is pretty advanced in terms of the level of sophistication and integration from the perspective of typical Salesforce implementations. Using a PWA or scaling massively using Apache Kafka may not be common, however, the purpose of this content is to expand everyone’s idea of the realm of possibilities that exist in the Salesforce ecosystem.

As a Salesforce administrator or developer, I find that it’s somewhat easy to get a bit of tunnel vision and somewhat “stuck” in our thinking in terms of possibilities when architecting an application in the ecosystem. Therefore, I find it refreshing to look at examples that really push the edges of what is possible to build.

For more information, trailhead modules, and advanced topics related to scaling Salesforce apps with Heroku and event-driven architecture, check out the links to the resources below:

In the next article, we’ll walk through unit testing methods and tools for Javascript applications.

If you haven’t already joined the official Chatter group for this series, I certainly recommend doing so. This will give you the full value of the experience and also pose questions and start discussions with the group. There are often valuable discussions and additional references available, such as presentation slides and other resources and references.

https://sforce.co/34Ld7xz

Scale Salesforce Apps Using Microservices on Heroku

Jason Sun — Sat, 30 Jan 2021 04:10:49 +0000

(Heroku and Salesforce - From Idea to App, Part 8)

This is the eighth article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Automating Business Processes Using Salesforce Flows and APEX

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

Last time we explored ways to automate back-end processes on Salesforce using Flows and APEX and created several automations for our eCars app using Record-Triggered Flows and an APEX trigger. This time we are focusing entirely on how Heroku apps and microservices can help our Salesforce app scale for high-volume use cases.

Setting Up the App and Scratch Org via Github

The eCars app Salesforce and Heroku code are available on Github at the following URL:

https://github.com/trailheadapps/ecars

Go to the apps->ecars-services directory for the specific Heroku services code for this session. The readme section in the directory contains useful information for deploying to Heroku.

To get things set up we’ll need to deploy the Salesforce application to a Salesforce scratch org as well as the Heroku apps to the Heroku platform. If you are jumping into the middle of this series and have not yet set up your scratch org, it would be a good idea to go back to the first article in this series to review how to set up scratch orgs and your Salesforce dev hub as well as sign up for a free developer account on Heroku.

To get a high-level idea of the architecture of the app, the following slide details how Sales Cloud and the Car Order Configurator will be interacting with the Heroku app and its microservices.

For deployment, we get two different methods on how to manage this (1) Automated and (2) Manual.

To start, let’s review the steps for Automated Deployment as also listed on the readme section in the Github repo. Julian has created a script (a Node.js program that will make this process easier) to get this up and running in the Salesforce and Heroku platforms. All of the installation pre-reqs, keys, and steps to configure your operating system before we move forward with deployment can be found here.

The automated deployment instructions reminds us of a few things: You must be authenticated in DevHub using the SF CLI and Heroku CLI, and you must have access to the repository in order to clone it:

After cloning the repo and opening the project in VS Code, we can execute the eCars deployment script using the node binary + javascript file. This will show you a screen asking you various questions. It’s important that _developers read through all questions in detail _because it will tell you the applications you are going to deploy. The script checks for git, node, SF CLI, and the Heroku CLI to ensure all the prerequisites are there. The script also requires you to answer a series of questions before continuing and then the deployment will take approximately 10 minutes to complete. This might be a step where specific system configurations or pre-requisites get missed and you may get error messages. If so, you can post on the Chatter group discussion forum for this series to ask for help.

The output of the script final steps of instructions

The goal of this is to simplify the process for you as much as possible. The final items are “post-deployment steps” to perform after completing the automated deployment. For extra credit, check out the Manual Deployment for further understanding and learning (as well as a place to check out more detailed information should you run into errors during auto-deploy).

In the JavaScript file, we have SF CLI commands, Heroku CLI commands, as well as Linux commands to perform automation. This is an example of a robust use case for devs on what you can do with a node script. Julian, the developer who authored the script, used the Shelljs package (you can check out this powerful library here – note the weekly downloads!) because it provides the ability to write an automation that can run in both Windows and Unix platforms. It is an “implementation of Unix shell commands on top of the Node.js API” which you can review in more detail on the README here.

Deep Dive into the Node.js code and useful functions/scripts

Those of you familiar with Node.js will know that you can use core modules as well as extend things easily with third-party modules. In this case, the Shelljs library provides the JavaScript object (JSON) that contains all of the required content to execute the external commands. Check out the screenshots below which show examples of exporting the commands from the index.js file and requiring them in our ecarsDeploy.js file.

Exporting the functions as JSON

Requiring them in the ecarsDeploy.js file

We continue to break down the modules and the code that starts the deployment process by function.

With javascript and Node.js, it’s important to get familiar with the well-known asynchronous functions that contain a command and then a callback function that runs when the external function or callback completes. Unlike strict-typed languages like APEX, things don’t execute in one thread so we have to manage cases where the external function/callback might run into a problem and never give us the callback. Since we don’t want to block execution and end up waiting forever for the callback, the standard in dealing with asynchronous operations like this is to use the async/await pattern. This relies on something called “Promises”, which all javascript developers should be familiar with. Promises allow you to execute async operations and guarantee they will return a value back without blocking the main execution thread.

Example use of a Promise

Another useful tool is the sed (“stream editor”) Linux command that allows you to replace strings in a file. Our app uses the sed command to access a template and substitute the correct URLs.

This command is extremely powerful because it gives you the ability to use the sed command to quickly modify metadata before pushing it into Salesforce.

The PDF Creation Microservice

A common request for applications like the eCars app would be to generate a PDF document from data collected in the system. In this case, we are going to create a PDF of a car configuration that can then be printed by the sales user for the customer. Creating PDFs is actually a high-cost CPU operation, relatively speaking, so we are going to leverage a Heroku microservice to offload this from Salesforce to Heroku.

Architecture and components between SF and Heroku for PDF generation process

Here’s what we will expect to happen once this is implemented. A potential customer builds a car on the eCars app and submits a request for it. This creates a lead in Salesforce. In Salesforce, on the lead record, we can then access the Web Push Notification (another Heroku microservice) telling the lead their car is ready.

Now let’s say your lead is at the dealership and building a different version of the car. In the Car Configurator, a sales user can walk through the steps of model, color, and interior and can then attach the lead in Salesforce and generate a PDF with the car’s details.

This PDF will be generated in Heroku and come over as an attachment on the files related list on the Lead record in Salesforce:

So how do we do this? First, the configuration information data gets sent from Salesforce to the Heroku microservice. Heroku is using Node.js and a few libraries/modules to achieve this—specifically, Fastify, PDFmake, and JSforce. One of the beauties of Heroku is the ability to combine all of these libraries to build powerful applications for a variety of use cases. Now some descriptions of each library:

Diving first into Fastify, we are using Piscina to help offset the load on the Heroku service as generating PDFs can be an intensive CPU operation. Piscina is a library to help manage something called the “workerThread” to generate the PDF and “downlog” the main thread of the application. This is implemented as a POST route, so we can have an APEX class in Salesforce that makes a callout to that endpoint via a POST method.

Then we have a PDFGenerator class in the PDFMake library to be able to generate the PDF. This includes the savePDFtoLead custom function that saves the PDF to the Salesforce lead.

Finally, jsForce is a javascript library that helps with interacting with the Salesforce REST API in javascript applications. In the jsForce code, there are functions to authenticate and create a connection to Salesforce as well as functions to send a SOQL query to Salesforce and get back and parse the results of that query.

To handle the PDF generated by the PDFMake library, we are receiving our PDF as a buffer and writing it back to Salesforce as a ContentVersion record (basically Salesforce Files) to the Lead record we retrieved in our previous query.

You can move a lot of this around and re-architect it as you see fit. This is one of the powerful things about microservices. Mohith mentions that devs overwhelmingly agree that “services should be as dumb as possible” to avoid creating any dependencies and can exist as the simplest and most atomized version of the service. This allows you to scaffold things up with multiple services and extend things more easily.

For some homework, you’ll want to check out the car-configurator LWC and explore the front end of the eCars app as well as the PDFCreateService APEX class to see how it is implemented to work with the microservice.

And don’t forget to explore the sample app gallery on Github.

Concluding Thoughts

In several of my clients’ projects, I was brought in because the internal admin or a previous developer got “stuck” trying to implement a particular requirement that was seemingly impossible to do with Salesforce because there was no declarative solution or way to do something in APEX code. Often in these cases, an external microservice solved the problem.

Once you realize that Salesforce has the capability to make web service callouts to external services, really the sky's the limit for what can be implemented when you combine Salesforce with microservices. It’s also important to remember that not only can Salesforce make callouts to external services, but external applications can make callouts to a number of Salesforce APIs to allow for bi-directional interactivity between Salesforce and third-party or homegrown applications.

Salesforce has so many APIs, it’s sometimes easy to forget what’s possible

In the next article, we’re going to do some additional work with Salesforce and Heroku microservices in a second part for this topic. Yes, there was too much good stuff to fit into one episode!

If you haven’t already joined the official Chatter group for this series, I certainly recommend you do so. This will give you the full value of the experience and also pose questions and start discussions with the group. Oftentimes, there are valuable discussions and additional references available there such as the slides from the presentation and links to other resources and references.

https://sforce.co/34Ld7xz

Automating Business Processes Using Salesforce Flows and APEX

Jason Sun — Wed, 20 Jan 2021 00:28:45 +0000

(Heroku and Salesforce - From Idea to App, Part 7)

This is the seventh article documenting what I’ve learned from a series of 13 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

Lightning Web Components, Events and Lightning Message Service

Just as a quick reminder: I’ve been following this Trailhead Live video series to brush up and stay current on the latest app development trends on these platforms key to my career and business. I’ll be sharing each step for building the app, what I’ve learned, and my thoughts from each session. These series reviews are both for my own edification as well as for others who might benefit from this content.

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

In the last session, we went into detail on Lightning Web Components (LWC) and built out a custom front-end experience by creating a custom inventory gallery for our eCars application. We also went through all the design tools and resources available to LWC developers such as the Salesforce Lightning Design System and Lightning Web Components reference library.

This time, we are shifting gears and reviewing ways to _automate _business processes. As developers, we know how to handle complex use cases with code, but Salesforce also offers a powerful, declarative way for us to do this: enter Flows.

Introduction to Salesforce Flows

Flows in an automation tool that allows you to automate processes in Salesforce without having to write code. Although flows are considered a “declarative” or non-code method of automating processes, it’s important that developers learn how to use Flows even as some of these processes may be managed by a Salesforce Admin moving forward. It’s also important for developers to learn since Flows can integrate with APEX via invocable actions and Lightning Components.

Flows offer a powerhouse of tools with easy to use drag-and-drop elements. Salesforce even offers a UI element known as Screen Flows which allows you to build a multi-page process or wizard. There are also pre-built solutions on the AppExchange that allow you to install packages with flows and combine them with your org’s pre-existing flows.

Flows are somewhere near the middle of this spectrum

Automating the eCars App Using Flows

In our first activity with Flows and our eCars app, we will populate a Range, using automation, based on a car’s price.

This can also be done using APEX triggers, Process Builder or Workflow rules, but today we are going to automate this using Flows. When creating a new flow in Setup, you’ll see that Flows can be triggered in multiple ways.

Screen Flows give you a way to build screens for lightning pages, communities or quick actions so that users can initiate the actions and go through a series of screens with ease. This type also supports integrating lightning web components into the flows.
Scheduled-Trigger Flows allow you to specify a frequency (“this should run at 3am every day”) for when a flow should run.
Platform Event-Triggered Flows offer a way to run an automation based on platform events. If you are new to Platform Events, check out this Trailhead Module that will help get you up to speed.
Autolaunched Flows can be invoked by APEX, process builders, other flows, or even called via the REST API and used with Einstein bots.
Record-Triggered Flows are flows triggered by changes to records, such as when records are created, updated, or deleted. These are very similar to process builders, workflow rules, and APEX triggers.

Today we are using the Record-Triggered Flows which allow you to run automation logic when a record is created, modified, or deleted. In the flow builder, we select when we want the flow to run. It’s important to keep a best practice in mind though: When updating the same record that you are evaluating, select “before the record is saved,” since selecting “after record is saved” can result in recursions or infinite loops. This occurs because the “after record is saved” run mode will update the record again and cause the flow to re-run.

Another thing to be aware of is the order of execution when mixing different methods of automation such as APEX triggers, flows, and process builders (here it is for quick reference). Oftentimes when mixing these different methods, it’s best to use an APEX trigger, since they provide the most granular control over what executes and when.

There are also some limitations to be aware of for the record-trigger flow. Specifically, these Flows don’t let you use the ISCHANGED() or PRIORVALUE() functions (but this will be changing in the Spring ‘21 release). Some helpful architect documentation is available on the Architect Website here. There, you’ll see what is currently available, as well as the roadmap for upcoming changes/releases to flows. If you have a truly complex use case, resort to APEX code. Alternatively, mix and match flows and APEX in a sensible way. For example, launch a flow and add an APEX element to it. (You can call APEX methods or Lightning Components from flows!) Because you don’t want your flow to become so complex that it is hard to maintain or debug, it’s key you check out the Architecture Guide to understand when you should use what.

Back in our flow, we select our object and pose the question, “When do we want this to run?” Or, phrased from a developer’s perspective: This is your “if/else statement.”

For now, we set this to “None” which will cause it to run under all conditions:

We bring in the “Decision” element and review our requirements once more so we can build out this logic into our flow:

Now we can build in these conditions where we will be checking the price of the vehicle and enter the outcomes we wish to occur depending on the price.

Next, we drag the “Assignment” element into our flow and go through the steps to map the range field’s corresponding value:

There are different options for assigning a value, and in this case, we will use “Constant:”

We can repeat the same steps for a second “Assignment” element for medium range as well, and then finally connect our elements together:

Adding lots of elements can quickly create a big of a mess on the layout, but there is a new feature called “auto-layout” which automatically cleans things up and organizes them in a neat and tidy way:

Even though flows are extremely powerful, there are just three logic elements in the toolbox: Assignment, Decision and Loops.

Assignments are where you can create variables and assign values to them.
Decisions are like “if” statements for evaluating conditions.
Loops are like “for loops” to control logic that needs to repeat until an entire list of variables has been processed (or some condition is met).

Over in the “Manager” tab, we can see all the elements created so far. These are the variables that have been created in the course of the previous steps.

The funny thing is that pretty much every programming language I’ve come across has these same core elements just expressed with slightly different syntax. So if you’re an admin who’s already a pro at building flows and can think through the necessary logic and architecture to build them in an elegant fashion, taking the next step and developing in APEX code should be a simple transition. Essentially, you are already doing low-code programming with flows.

Testing and Debugging Our Flow

For debugging record-trigger flows, we can only test this from the record. Test the flow we just built, save and activate it, navigate to a car record, and change the price of a car, then confirm that the range field auto-updates to the expected range value. Success!

More Flow Features and Other Flow Execution Types

Back in Flow Builder, if you select a new record-triggered flow but then choose “After the record is saved,” you can see more elements in the toolkit. This execution mode has more features; now we have an “Action” as an option as well as additional data elements.

Note from earlier that “before save flows” are only meant to modify the same record, whereas “after save flows” allows you to handle other data operations.

For the Auto-Launched Flow option, there is a “Subflow” action in our toolbox. This allows you to call a Flow from another Flow. Similar to object-oriented programming, this allows flows to be re-used in a modular fashion. An expert programmer, whether using flows or APEX, is always thinking about being parsimonious and efficient. They’d rather avoid repeating the same code or set of flow logic over and over again!

Another option worth mentioning is that you can choose the security mode your flow runs. This includes a feature that lets you run the Flow with the same data security and access rules that admins have configured for the current user, or allow the flow to bypass these rules or run in “system context.”

With Flow Actions and Flow Screens, you can build a step-by-step wizard or custom process within Salesforce. Flow Actions allow you to create a piece of logic in APEX and bundle it so that an admin can simply drag and drop it within a Flow. With Screen Components, you can do the same using Lightning web components, further empowering admins.

These flow bundles are available for those building AppExchange applications. They are also fully compatible with Continuous Integration/Continuous Deployment (CI/CD).

Flows are stored as metadata behind the scenes that you can view them as XML. As a result, it’s versionable and can be in a Git repository (just like all of your other code) and moved/deployed between different Salesforce instances.

Introduction to Salesforce APEX

Even though there is so much that can be done with Flows, there are still cases where it’s best to use custom code and APEX. APEX is a strict-typed, object-oriented language similar to Java. In a few bullets, APEX is:

Salesforce native programming language
Object oriented (classes, interfaces, inheritance)
Strongly typed language
Compiles to Java Byte Code
Includes SOQL and DML statements similar to SQL stored procedures

Now that we know what APEX is, it’s important to know when it’s appropriate to use. It’s somewhat rare to need any APEX, given all the declarative features that Salesforce provides, but certain use cases do call for it. For instance, it can be useful when you need to:

Create custom transactional logic (logic that occurs over the entire transaction, not just with a single record).
Attach custom logic to another operation, such as saving a record so that it occurs whenever the operation is executed, regardless of whether the operation originated in the user interface or via a API transaction.
Create bundled APEX to be invoked from Lightning components, Visualforce pages or Flows.
Perform complex logic or validation over multiple related objects.
Create custom web services.
Create custom email services.

With the first two, it’s not necessary to use APEX, but with the last three items, there really is no alternative to APEX. In fact, one of the main uses of APEX in my current experience on client projects is to create custom REST web services. Doing so allows an external application to make POST, PUT, or GET requests to Salesforce and have the requests processed in a custom fashion.

Automating Tasks for the eCars App with APEX

Our example use case for APEX and our eCars app will be to create a task for our sales reps after a vehicle status is set to “sold.”

When first starting out doing development, I did a lot of copy-pasting and editing existing code. There is no shame in this; it’s all part of the learning process. Luckily, in the APEX Recipes Github repository, we can find some APEX Recipes with bite-sized snippets of code for almost everything that you might need. The code samples found here are also “production quality,” so it would be a useful exercise to review and compare it with any existing code you’ve written to gain some insights into what Salesforce considers best practices.

The recipes include integrations, SOQL, DML, and other use cases. Each of these recipes is paired with documentation. The recipes also encompass best practices around writing secure code. When writing APEX, we sometimes want the permissions that are configured for an object to be enforced. This needs to be handled explicitly in code— a useful recipe to review is the “CanTheUser” recipe.

It’s important to note that even though you can create multiple APEX triggers for an object, you should never do so. If you did, it would be easy to quickly lose control over the execution of the transaction, as the order that the triggers are fired is not guaranteed. Therefore, it is recommended you write only one trigger per object and have a delegator pattern in place—that is where a TriggerHandler comes in. A common pattern that I use for all triggers and handler classes is as follows. You can see that having a dedicated handler method allows for more granular control in each execution context.

trigger ObjectTrigger on Object__c (before insert, before update, after insert, after update, after delete, after undelete) {
    if(trigger.isBefore){
        if(trigger.isInsert){
        ObjectTriggerHandler.handleBeforeInsert(trigger.new);       
    }
    else if(trigger.isUpdate){
            ObjectTriggerHandler.handleBeforeUpdate(trigger.newMap, trigger.oldMap);       
    }   
}
else if(trigger.isAfter){
        if(trigger.isInsert){
            ObjectTriggerHandler.handleAfterInsert(trigger.newMap);
    }
    else if(trigger.isUpdate){
            ObjectTriggerHandler.handleAfterUpdate(trigger.newMap, trigger.oldMap);       
    }
    else if(trigger.isDelete){
            ObjectTriggerHandler.handleAfterDelete(trigger.oldMap);       
    }
    else if(trigger.isUndelete){
            ObjectTriggerHandler.handleAfterUndelete(trigger.newMap);       
    }
}
}

Using a combination of what we’ve learned so far and the APEX Recipes library, it should be relatively straightforward to implement the task automation for the eCars app. If anyone is having problems, the Chatter group dedicated to this series would be a good place to ask for help with your code.

Concluding Thoughts

With so many ways to implement a particular use case, it’s important that we talk about which tool to use when and to review best practices. Do you use APEX only, Flows only or a hybrid approach? If you’re unsure, it’s useful to refer back to the Architecture Guide Quip document. A summary of the key deciding factors is as follows:

You should typically choose the tool that allows you to build and maintain the solution at a low cost:

If you have APEX developers available and have well-established CI/CD and trigger frameworks in place, adding Flows to the mix can unnecessarily add overhead.
If your application will be maintained by admins or non-developers in the future and there is less access to developers, then Flows may be the best choice.
If you have a combination of devs and admins, you can consider using flow triggers with complex multi-record processing logic in an APEX layer that is exposed as services/actions for flows.

At the time of this writing, APEX developers are in short supply as compared to Salesforce admins, so it’s usually natural to avoid APEX for as long as possible. However, in certain cases, it’s very easy for flows to quickly get too complex, out of control, and unmaintainable. This is especially true if thought isn’t put into how the flows are architected and organized. It’s also important to revisit existing flows periodically to see if they can be refactored to be more modular or maintainable. I’ve seen many orgs overuse flows when a little bit of APEX could have been a more effective solution. When that happens, the organization has to spend a great deal of resources trying to fix/refactor a mess of flows once things start breaking and error messages start popping up. As a result, an ounce of prevention in this case is worth many pounds (and hours) of technical debt!

In the next article, we’re going to look at scaling Salesforce applications with microservices on Heroku and building using an event-based architecture.

https://sforce.co/34Ld7xz

Lightning Web Components, Events and Lightning Message Service

Jason Sun — Mon, 28 Dec 2020 16:57:51 +0000

(Heroku and Salesforce - From Idea to App, Part 6)

This is the sixth article documenting what I’ve learned from a series of 12 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

Custom App Experiences with Lightning Web Components

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last Time…

In the last session, we went into detail about considerations and tools related to customizing app experiences, from point-and-click methods all the way to fully custom code. However, we only briefly touched on the featured go-to custom code framework: Lightning Web Components, or LWC.

This time, we’re taking a deeper look into LWC and also covering how to communicate between components in our eCars app using Events and the Lightning Message Service.

Like Normal Web Components… but With More!

LWC are built on top of regular web components (WC) which almost every web application developer should be familiar with. In a previous article, I commented on how smart it is for Salesforce to move from SFDC-specific frameworks (like Visualforce) to LWC, since this allows most web developers to build on the platform with less of a learning curve. On top of that, web components are modern, interoperable, future-proof, and backwards compatible.

The idea underpinning LWC is the open-source framework that has a compiler and Lightning-specific properties. This provides what Mohith Shrivastava calls “sugar” on top of a web component.

The verbose WC syntax then becomes really simple; we can add styling using the Salesforce Lightning Design System (SLDS) as well as Metadata.

Sweet!

For those of you, like me, who may have come from “Visualforce/APEX land” and find LWC somewhat of a fresh concept, remember this: when you are learning LWC, you are learning the standard web components as well. Two birds, one sweet framework.

Another important tidbit for those of us coming from APEX/Visualforce: JavaScript and thus LWC are CaSe sEnsiTive so if you’re used to APEX code being case insensitive, save yourself a lot of debugging and don’t forget to use camelCase or kebab-case where needed.

Building Out the Enhanced eCars Inventory Gallery

Let’s jump into the first activity, where our goal is to build our custom inventory list experience for the eCars app. In the previous article, we created a prototype using a Salesforce Lightning Design System (SLDS) plug-in for Sketch. We also used standard SLDS base components to arrive at this enhanced layout:

Certainly nicer than a bland list view

We will build in our IDE of choice, Visual Studio Code. You’ll need a scratch org and Salesforce-specific extensions for VS code to get started. If you are just finding this article now and are not yet set up with a Salesforce developer account, dev hub, and scratch orgs, go ahead and jump to the first article of the series to get those things set up. Once that’s done, you’re up and running and ready to develop.

When building LWC, the component-reference documentation is GOAT (greatest of all time). Salesforce has invested a lot in giving you “pre-baked components that have a lot of functionality,” including providing HTML, CSS, and Javascript code out-of-the-box. These are largely the same components you’d find in SLDS, so the design process and the code implementation are going to flow naturally. One of the components we used for the Sketch design is available in the component reference, of course: the Lightning Card.

An all-you-can-copy-and-paste component buffet

We can proceed by just pulling in the pre-baked code for the Lightning Card component we want to use. At this point, it’s useful to understand the term “slot.” A “slot” is a placeholder in components where you can add your own component or HTML mark-up. Mohith also reviews badges documentation and pulls in a stand-in image. With a refresh to our local dev server (Code Preview), we can see the beginnings of the inventory card.

We can then expand on this single inventory card component and create iterations of each card that will pass data from the Vehicle__c Salesforce custom object records to this new inventory component. We can bind the data properties from Salesforce data to our component using the @api decorator.

LWC adds a lot of utilities for you to create flow control for apps including repeaters and conditionals. You can check them out at lwc.dev where you’ll learn all the fundamentals like templates, data binding, and development lifecycle.

Design Help for Developers

Developers and designers are usually not the same people, and the skillsets don’t always overlap. As a result, it’s very nice to have libraries and design systems like SLDS and the LWC component reference, since they take care of a lot of the design thinking for us developers. But of course, if you are a developer/designer hybrid unicorn and have the CSS background, you can build onto SLDS with your own designs and create amazing interfaces.

In the documentation, we have a lot at our fingertips. We even have a playground to learn about different ways to size our layouts; we are encouraged to try different options to understand what type of layouts are actually possible. Developers even have the option to build out layouts that are automatically responsive.

I personally love what the SLDS has done: it’s given us utilities so that we don’t have to actually worry about them. For example, if we want to add some padding somewhere, we can look at the classes in the documentation, find the appropriate one, and simply copy-paste the class to our component. Using on-page or in-line CSS should be a rare case and avoided whenever possible.

Back to App Building

Moving forward in the walkthrough, we get our component set up and preview it locally:

Looks like we are almost there!

There are certain properties in Lighting Layouts that we can use to our advantage. In this example, we want multiple rows, which means we get to play with the size element. In VS code, if the LWC extension is installed, hovering over an element shows all its properties. Then we can start typing it in, find what we need, and let the auto-complete save us time.

This will save me lots of Google searches

Events in Lightning Components

We need Events to handle transmitting data in LWC between separate components. That’s because they do not automatically communicate with each other, even if they are organized as parent-child components. (Maybe the child is a broody teenager?) But jokes aside, this is by design and for security reasons. That way, foreign components embedded in the same page cannot “spy” on another component’s data.

The important thing to remember with Events in LWC is that “if you do not have a strategy, you can quickly mess up your architecture without following a consistent design pattern.” The best practice for child-to-parent components is to always use Events. In our eCars inventory gallery, we add a function where clicking one image will mute or “blur” all others on the screen. The blur effect is done in CSS, but handling the event to blur/unblur the appropriate cards requires Events and JavaScript.

We create a JavaScript event (new CustomEvent = ‘cardselect’) and pass the vehicle’s VIN so we can identify which element is being clicked. We dispatch the Event on clicking the card, but how can we have the card component listen for this? We can go into the HTML element for the inventory-card and add an “oncardselect” property calling a function, our handler.

We can then add our handler to our JavaScript with a map function to return the modified element, followed by the @track decorator to ensure we have reactivity when we are interacting with our app.

_ Lightning cards go blurrrrrr_

Concluding Thoughts

I remember the first time I went through a Visualforce tutorial. I needed to review existing working example code, modify it, break it, and build it back up again. I anticipate I’ll have to do the same with LWC, and also work through some practical exercises to build up experience and confidence with the framework. I would love to hear from those who are familiar with regular web components on how similar this is to them and how quick the transition is from regular WC to LWC. Luckily, I have a backlog of Visualforce pages from Salesforce orgs that I manage—they could use some conversion to Lightning Web Components. I reckon I’ll get plenty of practice with LWC that way! There is also a nice sample app on github from the Developer Advocate Team that actually demonstrates how to do this.

In the next article, we’re going to look at automating back-end processes and logic for our eCars app using Flows and APEX.

https://sforce.co/34Ld7xz

Custom App Experiences with Lightning Web Components

Jason Sun — Thu, 17 Dec 2020 02:54:04 +0000

(Heroku and Salesforce - From Idea to App, Part 5)

This is the fifth article documenting what I’ve learned from a series of 10 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Building Front-End App Experiences with Clicks, Not Code

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Previously…

Last session, we covered some no-code, point-and-click ways to control and customize the UI/UX experience on the Salesforce platform when building apps. This time, we are looking at tools for building completely custom front-end experiences using code, and will apply those tools to our eCars app to create a custom UI.

Looking at the range of possibilities for customization, you could put creating the eCars UI on a scale from no-code to all-code.

C and D only come into play about 20% of the time

In my experience building Salesforce apps for my clients, I’ve found that Salesforce’s point-and-click tools usually satisfy 80% or more of the project’s requirements. In the other 20% of cases, some kind of custom Visualforce page or Lightning Component is needed for a particular use case. This is especially true when looking at internal-facing apps.

On the other hand, when building a public-facing customer app, or a partner-community portal on Salesforce Community Cloud, it’s about a 50/50 split. This is usually due to a company’s branding needs for their public-facing experience. I expect this ratio to shift even more in the direction of low-code or no-code in the future since Salesforce is always releasing new ways to empower the point-and-click methodologies of the platform. Finally, in certain cases, it actually makes sense to build parts of the app on Heroku when you get to very large scale B2C applications (greater than 50 million active users) with the added benefit of being able to choose the UI framework of your choice in Heroku.

Customization Considerations

Since implementing, updating, or undoing the point-and-click customizations are so fast, I’ve found it’s typically best to build out the minimally viable product (or MVP) for the application using point-and-click methods. Then, I extend certain parts of the application with custom code where needed. In my experience, beginning with an entirely custom build has only led to pain and suffering, as well as a much larger project budget.

Every now and then, a use case is overwhelmingly compelling for some kind of customization, or the client or project stakeholders insist on some kind of custom experience. With the latter case, I always try to talk them out of it and also warn them of the added costs of building, maintaining, and updating the custom code. If we don’t carefully control and document the code (and rarely do projects leave room for this), things can quickly go south as changes on top of “enhancements” pile up on the legacy code.

This happens surprisingly often

To try and avoid this situation, it’s always good to put the customization use case through its paces via a framework to see if it’s truly necessary. In the video series, Mohith, our Salesforce Developer Advocate, gives us a nice three-point checklist to go through to see if customization is necessary.

Checkpoint 2.5: See if a third-party Lightning Component on the AppExchange might work

SLDS and Design Tools

Let’s suppose we’ve gone through the process and found a compelling and proper use case to use custom code to create a custom experience for the app. We don’t just start putting pencil to paper and start coding. Oftentimes, the app feedback I get from stakeholders is neither specific nor detailed enough to be actionable. It’s usually something more ambiguous like “this page doesn’t show enough information” or “the UI is too clunky for my users to perform X process.”

At that point, the real fun begins. We have to tease out what the users really need to be built out for them through a process of sketching, prototyping, and iterating---all before actually committing to code. Luckily, there are a number of tools that can help with this process and make sure that we hit the sweet spot when it comes to working up a custom design.

It’s surprisingly easy to let these things get totally disconnected

Salesforce Lightning Design System (SLDS)

I’d describe the Salesforce Lightning Design System, or SLDS for short, as a cheat-sheet of all the UI components that comprise Salesforce Lightning Experience. Similar to Bootstrap— which some web developers may be familiar with— it’s an entire library of design guidelines, component blueprints, utilities, and design tokens, along with code samples. All the HTML and CSS has been provided so a developer can simply go through the SLDS library and pick out components to piece together for the build.

An example modal component with HTML sample and CSS classes already provided

SLDS Plugin for Sketch

There is also an SLDS plugin for Sketch that allows Sketch users to get access to all the components in SLDS. As a result, designers can quickly prototype something with SLDS components using the drag-and-drop design tools in Sketch. The only caveat here is that this plugin is currently only available for MacOS.

UI Toolkits for Sketch, Figma, and Framer

Fortunately, those who have something other than MacOS, or use something other than Sketch, can download the SLDS UI Toolkits to get the same components. Figma also happens to be a very popular design tool that I’ve come across several times while working with designers.

SLDS Validator for VS Code

Finally, the SLDS Validator is an extension for VS Code. It makes sure that if one gets deep into custom-code land, the code produced remains SLDS compliant and compatible with Salesforce Lightning Experience.

All of the aforementioned tools and more can be found on the Tools section of the Salesforce Lightning Design System site.

Improving the eCars App’s Inventory List View

In the context of Pulsar’s eCars app, we have an example use case for a bespoke front-end experience that requires some custom development. We’re presented with the following user story:

“Pulsar uses eCars Sample gallery apps. The current inventory page uses a standard list view to display inventory items.

Agents using the app have expressed that it would be visually helpful to them if they can see the car images for each inventory. The status field is not obvious and agents have asked to make it visually appealing.”

This gets the job done, but is certainly not visually compelling

I find that many clients and stakeholders are “show me” people. I need to put something visual in front of them to start collecting substantive feedback. If you go to the approximate halfway mark of the video, you get to see, first-hand, how we use Sketch and the SLDS plugin together to create our improved eCars wireframe after about 15 minutes of point-and-click work! And with the code samples already provided by the SLDS library, the developers will be happy that the designers didn’t go way off into left field with their designs. Put simply: a win-win.

Fifteen minutes of wireframing, hours of meetings and discussions saved

Concluding Thoughts and Other Helpful Resources

The session concluded with an interview with a real-life product designer, Brian Winterhoff from Carmax. I came away with two learnings from the interview :

There is often a learning curve for designers when transitioning from traditional web app development to Salesforce. With web app design, there is more of an empty canvas, whereas Salesforce provides some of the base UI. However, this apparent constraint actually allows for better collaboration between designers and developers when working in the shared context of the Salesforce Platform.
Even after going down the route of prototyping and iterating with designers, more often than not, they are able to find a non-code solution that works for the use case. This just goes to show that just because you’ve committed to wireframing a custom design, it doesn’t mean that custom code will be necessary to implement it.

After watching this session, the sketch tool is definitely something I’m going to start using more, now that I’ve seen how simple it is to use in conjunction with SLDS. I’m thinking this is going to save me (and a lot of other people) time when it comes to nailing down a custom front-end experience design.

For more information and specific practice on some of the topics covered, check out the links to the resources below:

In the next article, we’re going to continue on with Lightning Web Components and focus on a specific topic: communicating between separate LWCs using Events.

https://sforce.co/34Ld7xz

Building Front-End App Experiences with Clicks, Not Code

Jason Sun — Sat, 05 Dec 2020 04:50:55 +0000

(Heroku and Salesforce - From Idea to App, Part 4)

This is the fourth article documenting what I’ve learned from a series of 10 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles, we’re focusing on how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my previous articles, you can find the links to them below.

Modern App Development on Salesforce and Heroku

Jumping into Heroku Development

Data Modeling in Salesforce and Heroku Data Services

Just as a quick reminder: I’ve been following this Trailhead Live video series to brush up and stay current on the latest app development trends on these platforms that are key to my career and business. I’ll be sharing each step for building the app, what I’ve learned, and my thoughts from each session. These series reviews are both for my own edification as well as for others who might benefit from the content.

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

Last time…

Last session, we did some data modeling in Salesforce using point-and-click methods and also went over some of the data modeling and scalability features of the Heroku platform. If you remember from the last article, I absolutely think that proper data modeling at the outset is critical to setting up an app for success.

In this episode, we’re looking at a topic that is paradoxically both anathema to me_ and_ something that makes me love the Salesforce platform: creating front-end app experiences. I promise this will make sense as we get deeper into the article.

Ever since I first got into app development, designing and building front-end experiences for an app or website has probably been my least enjoyable experience. With back-end development, things either worked the way they should, or you had clear bugs or errors: there was no middle ground. On the other hand, I found front-end to be far too subjective of a topic for my liking—everyone had a different opinion about how something should flow, how it should look, whether to use rounded or square edges, which shade of blue would get more clicks, etc. Then, when you finally get to release the end product after much colorful debate, a group of users out in the wild invariably figures out a way to get confused by the front-end experience you worked so hard on.

The fact that there is massive controversy over this meme is why I dislike working on both

However, I think my early distaste for front-end related things is actually something that drew me deeper into the Salesforce ecosystem. I was naturally attracted to the platform’s meta-data driven architecture that allows me to quickly get an app concept up-and-running with a working and extensively customizable user interface without having to write a bunch of front-end HTML, CSS, and Javascript. Many of my clients are very visual in the way they process information, and oftentimes they need something in front of them they can play around with and “kick the tires” on before they’re able to provide substantive feedback on ways we can improve their experience. Being able to prototype this way has saved me countless hours iterating on designs.

As a result, this session really had me thinking about how much one can do with the front-end experience of a Salesforce app before having to do anything with code.

Let’s look at some of those features in the context of our eCars app.

Personalizing and Branding the Salesforce App

A nice feature that’s been added to the Salesforce Lightning Experience interface is the Themes and Branding section of the User Interface area of app setup. Without needing code to customize the color palette, banners, logo, and images, we can completely personalize a Salesforce app to match the branding of the company.

We can literally take theme customizations for a test-drive

You can try out this feature yourself in the context of the Pulsar eCars app by uploading the app package to a developer edition or scratch org. You can get the GitHub repo for the eCars app at the following URL and if you need a review on how to deploy a Salesforce app to a scratch org from a GitHub repo, you can refer back to the very first article I wrote on this series (link here):

https://github.com/trailheadapps/ecars

Creating Custom Record Pages Without Code

Being able to customize the theme colors, logos, and images is certainly a nice appetizer, but the main course is really when we get into the user interface components of record pages without having to use any code. Lightning Experience has really taken this to the next level as well—those of you too new to have known Classic Experience might not fully appreciate all the new features Lightning offers.

For the eCars app, we get to design, from scratch, a record page for the standard Lead object. Regardless of which object we’re working with, displaying relevant information to the user in both a logical and functional way is paramount. With the Lightning record pages, we’re presented with a plethora of variations on how we can optimize things for the user, all without code:

Page Templates

How should we organize information on the page? Do we need a header and two equal regions? A header, main section, and a sidebar? No header and three columns?

Even if none of the many out-of-the-box layouts work, we can create a custom page template that can be achieved with some light coding.

If none of these options work, you could be overthinking things

Drag-and-Drop Components

After the page regions are defined, we can simply start building out the record page using a number of drag-and-drop components such as tabs, record details, record highlights, related list items for the sidebar, etc. Basically, we can include anything that someone interacting with the record might need to access.

Page Activations for Different Use Cases

Once the page has been built and defined, we also have the option of activating it as a single org-wide default, or going a few levels deeper and then defining multiple versions of the same record page for different apps, user profiles, and record types. One user may need to see more, less, or different information for the same record. This reality makes defining multiple versions a handy tool to achieve that use case.

The page activations can even be as granular as desktop vs. phone for added optimization for the different form factors.

Even More Granular UI Elements Without Code

In addition to the customizations of the Lightning Record Pages, there are other, more specific ways to customize without code.

Compact, Search, and Page Layouts

If we need to customize which fields appear and in what order—in places like the Record Highlights component, the Global Search results, or the Record Details component— we can use drag-and-drop methods on the Compact Layouts, Search Layouts, and Page Layouts sections of the Object Manager in Setup. I use these frequently as they’re essential to organizing information for the users.

Dynamic Actions with Conditional Visibility

This is a relatively new feature at the time of this writing (only a few releases old), and it’s already helped me with those client requests that go something like, “Can we hide this button until so-and-so has filled out x,y,z or the record has gotten to this stage?” I used to hack this functionality together by creating a mess of record types and different page layouts, or I’d just code a custom visualforce page. But now, hiding/rendering actions is as easy as defining the filters for them with a few clicks.

The one consideration here is that this only works (currently) for desktop interfaces.

Dynamic Forms

Dynamic forms take the whole “conditional visibility” thing to a new level. This feature applies not just to buttons and actions, but to individual fields. Similar to the above use-case example for hiding buttons, sometimes a record just might present too many fields to the user at once. Dynamic forms solve this by allowing you to define under which conditions certain fields should be visible. As a result, users can go on about their business of filling things out and updating records. Then, as things progress, dynamic forms hide irrelevant fields and present new, relevant ones. This creates a nice, streamlined user experience.

One “gotcha” we have to keep in mind is that this is only available for custom objects, not standard ones like Leads, Accounts, Contacts, and Opportunities. That being said, I’m betting this will change soon enough.

Screen Flows – Multi-Step Wizards Without Code

Screen flows are probably one of the most powerful tools we can leverage when it comes to custom user experiences without crossing into the “code zone.” If an app builder needs to hold a user’s hand during a complex and multi-step design process, then the screen flow is the likely tool of choice. I’ve found that there is a bit of a learning curve with screen flows. Although it’s hard to design them nicely from the outset, once someone gets the hang of it, they’ll need very little time to build out a totally bespoke data-entry wizard user experience during those times when even dynamic forms don't get the job done.

And once Lightning Components get involved, flows can even launch and exchange information with Lightning Components in the middle of a flow. The possibilities really are endless.

Concluding Thoughts and Other Helpful Resources

As I said earlier, designing front-end experiences is not one of my strong suits. I’m pretty sure that if I had not found Salesforce on my app-building journey, I probably would have quit and found a different line of work, or I would have just become a purely back-end developer. The UI/UX tools and features on the Salesforce platform have instead helped me to deliver complete app experiences, front to back.

For more information and specific practice on some of the topics covered, check out the links to the Trailhead modules and resources below:

In the next article, we’re going to shift gears and dive into some actual coding for the eCars app with Lightning Web Components.

If you haven’t already joined the official Chatter group for this series, I certainly recommend you do so. That way, you can get the full value of the experience and also pose questions and start discussions with the group. Oftentimes, there are valuable discussions and additional references available there, such as the slides from the presentation and links to other resources and references.

https://sforce.co/34Ld7xz

Data Modeling in Salesforce and Heroku Data Services

Jason Sun — Sat, 05 Dec 2020 04:43:34 +0000

(Heroku and Salesforce - From Idea to App, Part 3)

This is the third article documenting what I’ve learned from a series of 10 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles I’m walking you through how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my first article, you can find the link to it below and start from the beginning. Otherwise, if you’re specifically looking for data modeling, you’re in the right place.

Modern App Development on Salesforce and Heroku

Jumping Into Heroku Development

The Trailhead Live sessions and schedule can be found here:

https://trailhead.salesforce.com/live

The Trailhead Live sessions I’m writing about can also be found at the links below:

https://trailhead.salesforce.com/live/videos/a2r3k000001n2Jj/modern-app-development-on-salesforce

https://www.youtube.com/playlist?list=PLgIMQe2PKPSK7myo5smEv2ZtHbnn7HyHI

On the last episode…

Last session, we walked through Heroku buildpacks and learned how to start building on Heroku with a particular web language. The buildpacks were nicely structured, with intuitive instructions and installation steps for getting Heroku and your local machine set up to develop on one of the supported languages. We also ran through the process of using the command line, VS Code, and specific Heroku git commands to deploy a sample Lightning Web Components (LWC) app to a new Heroku app environment. Not bad for under an hour’s work!

In this episode, we’re going to get into the bones of any modern application: the data layer.

One of the things I find funny about data modeling is that almost everybody does it in their regular work, but rarely do people think too deeply about it (unless they’re developers or DBAs). There’s also a really steep learning curve when you graduate from a flat file like Excel to a multi-table relational database like Access. Every client I talk to can describe, to a degree, what kind of data their business needs to track. But going beyond that—initiating the right conversations with clients, reading between the lines, and teasing out the best data model of their application—is somewhat of an art form. Data modeling also seems to be a bit of an underappreciated part of the application-building process. Speaking from experience, getting the data model right or wrong for an application can mean the difference between a smoothly performing app that generates useful, insightful data and an app that gets “spaghettified” with workarounds and code to make up for the data modeling missteps made at the outset.

A lot harder when you’re already a few million rows down the data rabbit hole!

Data Modeling in Salesforce Using Point-and-Click Methods

As we dive into our data modeling for the eCars app, there are two things worth noting about Salesforce’s data modeling features:

Standard Objects establish a data model right out of the gate for Salesforce applications.
Custom Objects and Custom Fields provide the ability to rapidly extend and prototype additional data requirements for any application.

They also touch on Big Objects and External Objects, but in my experience, these rarely come into play except for enterprise-level implementations that have large data sets and external data sources. For the most part, Standard and Custom Objects covers 80% or more of the use cases in my experience.

One major Salesforce data-modeling feature that requires experience and attentiveness is its attached dependencies and automatically generated metadata components. Many “freebies” and metadata dependencies come attached (i.e. conveniently created for you) to the custom objects, fields, and relationships that one creates in the system. For example, when you create custom objects and fields, the system already allows you to set and handle some things conveniently like creating a tab, default list views, page layouts, reports, and the security model down to the field level.

Creating a relationship field, such as a lookup or master-detail relationship, also conveniently renders the child object (i.e. the table on the “many” side of a one-to-many relationship) as a related list on the parent object’s record page so that navigation is easy and intuitive. Some key things to know about the two different relationship fields are below and also demonstrates the kinds of “freebies” or metadata dependencies that are generated with each type (rollups, sharing rules, etc.).

This all results in the ability to immediately interact with and prove out your data model in your app and make tweaks and adjustments quickly. I can’t count how many times this has come in handy when working with clients on the initial vision of their apps. Instead of having to create ERDs and work up the data model before putting pencil to paper, we can just go directly to prototyping in real-time. Plus, the Schema Builder conveniently draws out the ERD as the data model is built out. You’ll also see in the video that it’s possible to build out the data model visually directly on the Schema Builder!

Pretty nice when the data model comes with these freebies as it’s being built out

Building the eCars Data Model

By using the point-and-click data modeling features of Salesforce, we should be able to build out the entire eCars data model in under 20 minutes. The screengrab from the Salesforce Schema Builder tool below shows us the different tables/objects that are part of the app, how they’re related to each other (they’re all Lookup relationships here, no Master-Detail relationships so far) and which fields are required or automatically generated upon record creation.

A written interpretation of the data model’s relationships could be as follows:

A car can have zero, one, or more Configurations.
Each configuration can have zero, one, or more Car Options.
A Vehicle Order can act as a parent and/or child for a Configuration and vice versa.
A Lead can be related to zero, one, or more Configurations. (The data model implies that a Lead can be interested in multiple Configurations.)

Understanding what limitations and implications a data model conveys is one of the key skills in app development I’ve grown to appreciate.

Heroku Data Services

Data modeling on Heroku, on the other hand, follows some of the more traditional tools you might expect with SQL databases. Still, there are several GUI tools to help as well, which I’ll mention later. Heroku also features several important add-ons for scalability.

The four major data services we’ll focus on for the eCars app are:

Heroku Postgres (primary relational database)
Heroku Redis (in-memory key-value data store)
Apache Kafka (distributed streaming platform)
Heroku Connect (Connect Salesforce Data and Heroku Postgres)

Let’s look at each of those to see how we’ll use them.

For Heroku, while other 3rd-party databases are available in the Elements marketplace, the officially supported database of choice is Heroku Postgres and is appropriately the most popular Heroku add-on. Heroku, like Salesforce, allows you to create your data model on Postgres using both command-line methods such as in VS Code as well as through a UI via the Heroku application manager. I’ve also used pgAdmin to manage Postgres databases as well and have used it in conjunction with Heroku Postgres databases. I don’t know any people who purely live in the command-line when it comes to databases, but I’m willing to bet they’re pretty fast on the keys!

For the eCars app, we’ll use Postgres to store our basic relational data—customer information, car information, etc.

This is actually my first exposure to Redis and Kafka. However, after Julián explained the use cases for each, I can see how these are very important data services for highly scalable applications. Scalability seems to be more and more of a recurring theme for Heroku also.

Modern applications have to run lightning fast as consumers have come to expect that kind of performance. And even though solid-state drives might improve performance, the reality is that on-disk databases are just not going to be as fast as in-memory data. So, to get high-volume apps running super fast, you can see why you need something like Heroku Redis or Salesforce Platform Cache to store some of the higher-volume information that powers the app in fast, high-performance memory. Otherwise, the database would buckle under the number of requests.

On top of that, modern applications typically run on distributed cloud infrastructure and may be using multiple data sources which need a lot of real-time throughput. In front of the data sources are a collection of services, and we need a way to reliably and quickly pass messages among them. Apache Kafka on Heroku fits the bill for this requirement, especially in large enterprise applications. Apache Kafka is an event-streaming platform that will allow our eCars app to potentially scale to very high loads in a distributed app architecture. It also makes sense that there isn’t a free tier for this service, as I can imagine the expense it takes just to run one Kafka cluster.

Finally, Heroku Connect allows Salesforce data to connect with Heroku Postgres in a bi-directional manner with a quick set-up. This saves us from having to do a custom integration between Salesforce and Heroku Postgres, but usually the deciding factor is the cost. Using Heroku Connect will allow us to seamlessly and easily connect Salesforce data to Heroku Postgres in a bi-directional fashion in near real-time.

One thing I’d like to clarify (since it used to confuse me) is the difference between Heroku Connect and Heroku External Objects. While Heroku Connect works with Salesforce standard and custom objects, Heroku External Objects is strictly a uni-directional OData service, meant to allow Heroku Postgres tables to sync to Salesforce External Objects. The naming can get confusing, so it’s important to keep this nuance in mind. Heroku External Objects also comes with the Heroku Postgres add-on while Heroku Connect is a paid service.

Concluding Thoughts

That’s an overview of data modeling on both Salesforce and Heroku, and how we’ll get them to work together.

As I mentioned previously, I’m of the opinion that getting the data model right is probably one of the most important things when it comes to designing applications. If it goes wrong, everything can turn into a futile exercise, from the way data is collected to what the business intelligence/analytics tools produce.

I got introduced to this mode of thinking pretty early on, before I even started my career. A USC Marshall Business School instructor named Douglas Shook taught a database class to business students like me. I still credit that class, its data-modeling lessons, and the bit of SQL it taught us, with my eventual pursuit of Salesforce as my career. We did countless homework problems and quizzes where he would give the class a bunch of receipts and a report from a shoe store or something, and then ask us to draw an ERD for a possible database system that generated them. When I reflect on that experience, I definitely have some renewed appreciation for how Salesforce and Heroku make it simple to handle the data aspects of an app now.

If you want to take a deeper dive into data modeling considerations, I recommend taking a look at this article that Mohith wrote on Data Model Design Considerations When Building Salesforce Apps.

In the next article, we’re going to look at how we can customize the front-end UI components of Salesforce for our eCars app, all without writing any code.

https://sforce.co/34Ld7xz

Jumping into Heroku Development

Jason Sun — Wed, 02 Dec 2020 05:34:36 +0000

(Heroku and Salesforce - From Idea to App Part 2)

This is the 2^nd article documenting what I’ve learned from a series of 10 Trailhead Live video sessions on Modern App Development on Salesforce and Heroku. In these articles I’m walking you through how to combine Salesforce with Heroku to build an “eCars” app—a sales and service application for a fictitious electric car company (“Pulsar”) that allows users to customize and buy cars, service techs to view live diagnostic info from the car, and more. In case you missed my first article, you can find the link to it here:

Modern App Development on Salesforce and Heroku

This article is going to cover setting up Heroku, installing LWC, and setting up the deployment for our app.

As a quick reminder, I’ve been following this series to stay current on the latest app development trends on these platforms, which are key for my career and business. I’ll be sharing step-by-step building the app, what I’ve learned, some of the highlights, and my personal take on some of the content.

In the last article…

In the last article, we walked through an overview of the Salesforce and Heroku Platforms and how they can work together. We also did some pre-work to get set up for building the eCars app. So, if you are jumping in at this point, here are the following prerequisites you will need:

Getting a free Salesforce dev org: https://developer.salesforce.com/signup
Installing the Salesforce CLI: https://developer.salesforce.com/tools/sfdxcli
Installing Git (required for Heroku CLI): https://git-scm.com/book/en/v2/Getting-Started-Installing-Git (I also personally have Github Desktop.)
Installing the Heroku CLI: https://devcenter.heroku.com/articles/heroku-cli
Installing VSCode: https://code.visualstudio.com/ (I recommend also getting the Salesforce Extension Pack after installing VSCode.)
Cloning the eCars GitHub repo: https://github.com/trailheadapps/ecars

For this article, there is another free account to sign up to start exploring Heroku: https://signup.heroku.com/

The only catch with the “Free Hobby” version of Heroku is that the dyno will automatically turn off when it’s not in use. There is also a limit of 500 hours of uptime per month on the free tier. It seems pretty fair to me—if they’re going to offer me some free compute resources, it’s only reasonable that they turn off the lights when I’m not actively using the resources.

Diving into Heroku

Let’s start with an introduction to Heroku, all the bells and whistles it comes with, and how to get quickly up to speed with deploying an app on the platform. If you’re not familiar with Heroku, it’s a PaaS solution for quickly creating and deploying apps. With Heroku the idea is for developers to focus on building their app, and the platform takes care of the infrastructure stuff (DevOps, scaling, environments, and so on).

One of the handy things about Heroku is the Buildpacks you can select and launch right off the bat. I’ve played around with setting up an Amazon EC2 application server from scratch. I’m not afraid to admit that I spent a good two hours sorting through documentation and help articles just to install the right pre-requisites on the instance.

With Heroku, however, you can just pick your programming language and Heroku will quickly create a turnkey process with these Buildpacks to get going with a particular language.

Heroku has 8 main officially-supported languages: Node.js, Ruby, Python, Java, PHP, Go, Scala, and Clojure.

However, there are many community Buildpacks available for other languages and frameworks as well.

For the eCars app we’re building, we’re using the Node.js Buildpack. While, at the time of this writing, I certainly understand and can work my way through javascript code, I wouldn’t say I have as much depth specifically with Node.js as I have with Salesforce APEX and Visualforce code. However, I’m looking forward to diving a little deeper into Node.js as I consider it cross-training for Salesforce aura and Lightning Web Components.

Going through the Buildpack for Node.js is super simple. The step-by-step instructions and links to required installed components are very easy to follow and I found myself up and running with Node.js in under 30 minutes.

https://devcenter.heroku.com/articles/getting-started-with-nodejs#set-up

You should also install the current Long-Term Support (LTS) version of Node.js from https://nodejs.org/en/. At the time of this writing, the LTS version was 14.15.1.

Turnkey process and instructions for getting started with Node.js on Heroku

VSCode CLI Exercises and Installing LWC

I mentioned earlier that Node.js would be good cross-training for Lightning Web Components (LWC). In fact, the next step is to actually install LWC using npm, which comes with Node.js installed earlier.

https://lwc.dev/

After following the instructions at the link above on the VSCode command line, and answering three questions about the type of app I wanted to create, npm was quickly on its way installing all the dependencies for the LWC app. Although I don’t understand what all the installed dependencies mean, I can appreciate all the hard work that went into making the app easy to use.

After a few minutes of installation, the sample LWC app was up and running on my localhost machine on port 3001. At this point, one could continue building and testing the app locally until ready to deploy to Heroku.

Deploying the Local Sample LWC App to Heroku

Now let’s deploy to Heroku. Deploying the app to Heroku is a simple exercise. You only need to know several git commands with some Heroku flavor attached. Heroku is git-based so whatever you’re deploying needs to be under git source control. The commands to then deploy are simple and should be familiar to anyone who has used git commands on a command-line interface:

First, create your Heroku app with desired name

heroku create [app name]

Second, commit Something to Git for Deployment

git commit

Finally, push the Source to the Main Branch on Remote Heroku Git Server to Deploy

git push heroku main

There are some deeper level items on this topic, such as the Procfile and package.json. These files deal with the application’s dependencies and instruct Heroku on how to build and compile the application. For now, this is perfectly sufficient as I have moved a local application to the remote Heroku host URL to make it accessible on the web.

Dynos, Scaling, and Concluding Thoughts

The session on Heroku involved a deep dive into Heroku’s “dynos” or a unitized computing package required to run a particular app. Without knowing how this all works under the hood, what you need to understand is that Heroku has some easy-to-use scaling features that add scale and power to the application vertically and horizontally to guarantee a certain level of uptime even in the face of spikes in usage.

To scale horizontally, you add MORE dynos to your Heroku application. Doing so can let Heroku route incoming requests across more running instances of your web servers, which improves performance with high traffic situations. Adding more dynos also allows your app to process more tasks in parallel, and handle a higher volume of jobs. There are, however, some cases where scaling horizontally doesn’t help, such as bottlenecks on services and long-running requests. Usually in these cases, the individual dynos are overloaded so parallel processing doesn’t help.

On the other hand, vertical scaling refers to making each dyno more powerful individually. Upgrading dynos to larger dyno types will provide your app with more memory and CPU resources so that the performance of the individual dynos are improved.

So if you imagine a factory with machines making trinkets, you can improve throughput by adding more machines (horizontal scaling) or by making each machine run faster (vertical scaling).

When I hear stories about a website or server crashing due to a sudden influx of visitors, I often wonder what kind of infrastructure those sites are running on and whether they would have crashed if they were using Heroku.

After working on the Lightning Web components (LWC) part of the app, I admit that as someone who has lived in APEX and Visualforce for many years, I am anxious about the shift towards Javascript-based aura and Lightning Web Components as it involves learning and adapting to a new framework that isn’t always my first go-to for building custom UI/UX components in Salesforce. However, this is certainly a trend I will have to embrace since the larger developer population is composed of more people who understand and work with Javascript than those who understand APEX.

It’s smart for Salesforce to attract and teach an existing population of Javascript developers to further enrich the entire Salesforce ecosystem. However, the silver lining to keep in mind is the number of resources there are in the ecosystem to help first-time Salesforce, APEX, and Lightning Web components users get information and training on the platform in a very short time.

Ok - now we’re all setup with Heroku, LWC installed, and our deployment ready. In the next article we’re going to learn about data modeling in Salesforce, set up the data model, then explore the integration between the two platforms by connecting Heroku to the Salesforce data using Heroku Connect.

If you haven’t already, consider joining the official Chatter group for this series. It is a great opportunity to post questions and start discussions with the group. The slides from the presentations are also posted there after each session.

Link to the on-demand session recording:

https://www.youtube.com/watch?v=6pgwh5Vak0I