Category: Salesforce

Salesforce for VS Code: Apex Replay Debugger and More

Salesforce Extensions for VS Code ships every week with bug fixes and updates. This post discusses a few of the major updates that have been released recently.

Apex Replay Debugger preview

You may have seen the exciting news at TrailheaDX that we are launching a log-based replay debugger as part of Salesforce Extensions for VS Code. Apex Replay Debugger brings Apex debugging to the Salesforce platform for everyone. The debugger is now available as a preview and is (and will always be) FREE for everyone to use. Finally, right?

Apex Replay Debugger makes it easier than ever to solve problems with your Apex code. Running the replay debugger gives you the same features you expect from other debuggers. You can view variables, set breakpoints, and hover over variables to see their current value. The replay debugger can be used from logs generated by running tests or for debugging interactive or non-interactive code and can be downloaded and run right from VS Code.

Apex Replay Debugger also makes it easy to work asynchronously and collaborate with others to solve problems. Because you can launch a replay debugger session from any replay-enabled log file, clients and coworkers can share logs to help solve problems. To start a debugging session simply open a log file and right-click to launch the debugger. For details, check out our docs in the Visual Studio Code Marketplace.

If you just want to jump in and start using Apex Replay Debugger, go download it now.

ISV Customer Debugger

For ISVs, debugging can be a pain. You are allowed to debug your code, your customer is allowed to debug their code, but sometimes you need to debug all the code in order to track down a problem. ISV Customer Debugger has existed for a while in the previous IDE, but now you can use the ISV debugger right from Visual Studio Code. For more information, see the “ISV Customer Debugger” section of the Apex Debugger documentation.

Apex syntax highlighting improvements

You may have noticed that your Apex code looks a little bit nicer. We have been working to improve syntax highlighting for Apex to properly colorize all elements and SOQL queries. We aren’t finished yet, but you should see some big improvements. We open sourced the official Apex Text Mate Grammar so that it can be used in other IDEs and, if so inclined, people can contribute pull requests. Additionally, the grammar is published as a node module. In both locations, you will find the grammar file in the TextMate XML format and the Atom CSON format.

Apex syntax highlighting in VS Code respects your theme as well, so if you want to make customizations to how your Apex looks you can easily do so. Below you can see how the Apex code now looks with the default VS Code dark theme.

Visual Studio Live Share

Finally, I wanted to point out a new feature that — while not exclusive for Salesforce developers — is a really

noimage

ICYMI @ TrailheaDX’18: 5 Session Videos About Commerce Cloud, Marketing Cloud, and Service Cloud

There are a few clouds that Salesforce developers can use to drive growth to businesses and create personalized customer experiences. Commerce Cloud, Marketing Cloud, and Service Cloud all serve different functions: Commerce Cloud delivers seamless shopping experiences, Marketing Cloud drives consumer engagement, and Service Cloud is there for user support.

As a developer, you can use tools like APIs and SDKs to customize and power customer experiences through these clouds. At TrailheaDX’18, we showcased how you can utilize some of these tools. Check out some of our favorite Commerce Cloud, Marketing Cloud, and Service Cloud session recordings from TDX18!

Introduction to Commerce Cloud’s Open Commerce API’s (OCAPI)  

Connect external web applications like mobile apps, ratings and reviews, and more in Commerce Cloud with Open Commerce APIs (OCAPI). Get a crash course in improving core e-commerce functionality from principal software engineer Andre Huss and technical architect Jeff Labarbera. (Level: Beginner)

What’s New for Commerce Cloud Developers  

Product managers Andrew Lawrence and Terence Tirella and software engineer Jan Kruger talked about all the latest innovations for Commerce Cloud developers. A couple of highlights included a Swagger-based Open Commerce API (OCAPI) Explorer and the new Mobile-First Reference Architecture to serve as a framework for site design. (Level: Intermediate)

The Content Block SDK and the Marketing Cloud SDK Playground  

The new Content Block SDK allows developers to create customized block widgets, which in turn helps marketers create better emails. Product management directors Sanjay Nagamangalam and Donald Owens and software architect Thomas Besluau also gave an inside look into the Marketing Cloud SDK Playground. (Level: Intermediate)

Service Cloud Goes Mobile  

Product designers Liz Fox and Kristen Muramoto talked about delivering customer support on-the-go with native iOS and Android apps for Service Cloud. Developer highlights for these new apps include case management, bulk actions, and notifications. (Level: Intermediate)

Integrate Customer Experiences Across Commerce, Marketing, and Service  

All of the clouds we spoke about in this blog post can cross-function with one another thanks to Commerce Cloud Community Suite Cartridges for Marketing Cloud and Service Cloud. Learn how to get one unified view of your customers in this presentation by senior solutions architect Jonathan Langevin. (Level: Advanced)

Watch and share all the videos here!

More resources

Check out the Service Cloud Snap-ins for Mobile Apps SDK module on Trailhead.

If you can make it to Chicago this week, be sure to grab a Free Expo+ pass to Connections from June 12-14! It’s the can’t-miss digital marketing, commerce, and service event of the year and you’ll have the opportunity to dive deeper into all of those clouds.

Check out other posts in this series

noimage

Upcoming Maintenance on Developer Edition Sign-up for Summer ‘18

Heads up, Salesforce Developers and #AwesomeAdmins – we will be performing maintenance on our sign-up infrastructure this weekend to bring the Summer ’18 Release to new Developer Editions and Admin Playgrounds. During this maintenance window, you will not be able to sign up for brand-new accounts, but you WILL be able to access your existing accounts.

Here’s the timeline for this upcoming maintenance:

Friday, June 8th, 2018 at 4 PM PST: New Developer Edition sign-ups pause and maintenance window begins. Saturday, June 9th, 2018 at 2 AM PST: Sign-ups resume for users in the AMER (North, Central, & South America) & EMEA (Europe, Middle East & Africa) regions. Saturday, June 9th, 2018 at 2 PM PST: Maintenance window ends. Sign-ups resume for all users.

These times are approximate, so make sure you are following @SalesforceDevs on Twitter for updates. If you think you will need a new Developer Edition during the maintenance window, we encourage you to sign up for a new Developer Edition right away. Again, access to existing Developer Editions will not be affected.

Want to learn more about the exciting Summer ‘18 release? Check out our Summer ’18 Release Readiness broadcast.

Let’s Talk Metadata Retrieval

This is a supplementary post, related to our Getting Started with Packaging and Modular Development series.

In the first post of that series, we walked through an example of retrieving metadata in an unmanaged package and converting it into a format compatible with Salesforce DX. But what about metadata that isn’t available for extraction using that method? What does that workflow look like? What resources are available to help you figure out what metadata is even available for extraction?

That’s what we’re going to talk about in this post.

How can you see what’s missing?

Not every piece of metadata is currently available in the screens you can access via Setup. The Package Manager (AKA the place where you compose unmanaged packages) and change set UIs fall into this category. So how do you discover what metadata is really out there, and what metadata can still be retrieved?

My first stop is the SOAP API Developer Guide. It is the most comprehensive list of sObjects, their purposes and fields, and—most important for our purposes—the operations you can perform on them. Another great feature is the Data Model section, which has ERD diagrams (visualizations of objects and relationships) for a large number of built-in platform services. These diagrams can help you identify what sObjects are involved with the functionality or customization you’re trying to extract. For example, this is the ERD for working with Knowledge:

Just some of what’s included in the SOAP data models: Sales Objects, Content Objects, and of course, Salesforce Knowledge Objects.

As I worked on creating a Salesforce DX project with metadata I’d grabbed from an org via unmanaged package, I realized the metadata related to Einstein Bots my team and I had built hadn’t been pulled into the package. I double-checked the Package Manager menu, and didn’t see any obvious options. So I needed to determine if I could grab that metadata another way, like interacting directly with the Metadata API, or if that metadata would need to be manually re-created in other environments.

So I headed over to the SOAP API docs to see what sObjects I might need to work with and see what my options were.

Which objects do I really need?

If you’re lucky, when you go to the SOAP API docs, you’ll see the objects you’re working with included in one of the data model ERD diagrams. You can use that as a guide to then dive deeper into the steps I’ll talk about below. But if you, like me, don’t see the functionality you’re working with in any of the data models, you’ll need to investigate objects on your own.

I knew from the process of building bots and deploying them that part of the metadata involved Live Agent functionality. So I started with that section of the docs. I looked at the descriptions of the objects first. I focused on whether an object represented configuration details about my org (like the LiveAgentDeployment object) or whether it represented details

Why Representative Datasets Are Important for Computer Vision Models

Artificial Intelligence is everywhere these days. In fact, by 2021, over 75 percent of commercial apps are predicted to use AI. This can be a daunting statistic if you’re new to the AI game, but there are some basics you can quickly learn to help you become an expert.

In this blog post, we’ll be talking about:

What is computer vision and how does Einstein Vision relate Why a representative dataset matters when working with computer vision How to properly structure a representative dataset The importance of feedback loops and “Agile AI” Computer vision and Einstein Vision

Before we get started, I’d like to make sure we all understand a few terms I’ll be using in this post: computer vision, Einstein Vision, and datasets.

Computer vision (as an interdisciplinary field of study) is concerned with the automatic extraction, analysis and understanding (by a machine) of useful information from a single image or a sequence of images.

Einstein Vision is Salesforce’s proprietary computer vision technology (also a part of Einstein Platform Services) which lets developers harness the power of computer vision to build custom AI-powered apps fast (even without a data science degree!). Einstein Vision is comprised specifically of two different types of Salesforce’s computer vision technology: Image Classification and Object Detection. I’ll use Image Classification in my screenshots and examples further down in the post, but the ideas discussed are relevant for all Einstein Vision and Einstein Language services. To learn more about the features and differences between Image Classification, Object Detection, and Einstein Language, please visit our developer docs.

Finally, an integral part of any computer vision solution is the underlying data that has been used to teach the artificial intelligence exactly what to extract, analyze, and understand. “Datasets” is the term we’ll use to refer to this underlying data. They will be the focus of the rest of this post.

Why a representative dataset matters

First, let’s talk a bit about how computer vision learns at a high level. For the most part, it doesn’t just “know” things — you have to teach it much like you would teach a toddler.

The analogy I like to use is “What is an apple?” Think about how you would teach that to a toddler. Would you say to the toddler, “Well, the apple is red and curved and it has a stem”? No, you would continually point out examples of what an apple looks like in the real world and reinforce the concept of “That is an apple, and this is an apple, and that is an apple.” The toddler would learn what an apple is over time by seeing real examples of it.

The most important part of this analogy is the concept of “real world” examples. When I work with people who are interested in computer vision, a common sentiment is that the images used to train the AI model must be perfect example images of the object in question. I think of such images as “sterile examples,”

Working with Modular Development and Unlocked Packages: Part 1

Salesforce DX gives all of us building and delivering apps on the platform more options for how we go about our work. Over the next few weeks, we’re going to take a deeper look at the capabilities of unlocked packages and share some techniques your team could use when considering packaging or incorporating modular development in your app dev lifecycle.

We’re going to look at:

Part 1: What even is a package anyway? How can you start to experiment with segmenting your org? Part 2: How can you start to organize metadata from an app, let alone an entire org, into packages? How do you tackle organizing your metadata and projects in source control? Part 3: What do these changes mean for app builder workflows? What will happen if I install an unlocked package into my production org today? Part 4: How can you define a successful Git branching strategy that works best for most team sizes? How, when and where should packaging be added to your continuous deployment?

Before we dive in, please note: we’re going to assume you’re already familiar with the basics of Salesforce DX. If you need to brush up, check out our Getting Started series.

In this kickoff post, I want to take a closer look at what packaging actually is, and how to start experimenting with breaking up an org into more modular units. We’ll be working with the Easy Spaces sample app in this series, which is based on the app showcased during the opening keynote at TrailheaDX ’18.

Org-based, source-based and package development

An important shift in the discussions about delivering apps with Salesforce DX is that Salesforce DX introduces a different way to think about your application delivery cycles. If you’ve ever installed an AppExchange app, those features were deployed to your org using packaging. With unlocked packaging (Now in Beta), this way of deploying and organizing changes is available to customers and partners. And adopting packaging will impact how you’ll manage and think about the very structure of your Salesforce org.

To better illustrate this, let’s consider non-package-based development (i.e. the way that most of us have been building and delivering apps on the platform) as falling into the category of ‘org-based development’. Your production org is the ultimate structure, or source of truth, for all the work your teams carry out. Even if you’re using a source control tool today, your production environment(s) still hold the complete version of all your customizations.

With package development, you start to segment your org and your customizations into packages. The package will become the ultimate source of truth for whatever it contains, and you’ll bring different environments up to speed by installing your package(s) into those orgs. Those environments can be scratch orgs, sandboxes, and, of course, production. As you make updates to the metadata in your unlocked package, you create a new version of your package. Then you can install the new version in whatever environments you want to update. These

Summer’18: Pre-Built Themes in Lightning Communities

With pre-built themes for Lightning Communities in Summer’18, any customer, partner, or developer can create visually stunning experiences in Lightning Community Builder with access to more controls and tools. Summer ’18 and the roadmap for Winter ’19 are the next steps in a journey to make building beautiful experiences in Lightning Communities seamless for developers and admins. In this blog post, you will learn about the underlying technology powering our theming engine, the building blocks of our new pre-built themes, and best practices for developers to adopt.

Lightning Community theming

Custom themes and the theming engine for Lightning Communities were first introduced at Dreamforce 2016. Themes (and theme layouts) are how any developer can deliver a customized UI for communities while still taking advantage of the rest of the Lightning Communities platform (including Community Builder).

It’s important to remember that themes are designed to control the overall layout and styling of your community (Think of it like your HTML template and global.css).

Summer ‘18: Pre-built themes

With the Summer ‘18 release, we are introducing four pre-built themes that will be available to use across any Salesforce ‘out of the box’ Lightning Community templates: Customer Service, Partner Central, Customer Account Portal, Build Your Own and any custom template you may have developed.

These pre-built themes are built on top of our existing theming framework and the forceCommunity:themeLayout Lightning component interface. They take advantage of several new design property interfaces (color picker, image picker, slider) that are surfaced in Community Builder and also leverage our new theme swapping functionality that allows you to change the active theme that is associated with the community instance. This means that it’s easy to quickly change the overall UI of the community without impacting any of the underlying pages, page layouts and/or components.

What you should know about pre-built themes (with Summer‘18)

As a developer, you should check out theme swapping. With theme swapping, any custom CSS you have entered through the “</> Edit CSS” option in Builder is now tied directly to your active theme. For an existing community, ensure that any desired custom CSS you are using is copied to the newly selected theme.

Additional points to consider:

Saved settings: We automatically save and maintain any configurations you make to each theme so it’s easy to jump between themes without losing customizations. If you have tested multiple themes in a community, we recommend removing the themes you do not plan to use in that community (via Settings > Theme > Manage). Hero options: All pre-built themes come with an optional hero theme component for the Home page that is optimized for search, or “call to action” functionality and can be toggled on/off through theme properties. Audience targeting: The new theme components (ex: Compact Header) do not currently support component-level targeting (visibility). You can achieve this in three simple steps: 1) Create a new custom theme layout (via Settings > Theme > Configure) 2) Create a new page variation 3) Assign the

Convert JavaScript Buttons to Lightning-Friendly Alternatives with the Lightning Experience Configuration Converter

Are JavaScript buttons getting in the way of your move to Lightning Experience? The Lightning Experience Configuration Converter can help. With just a few clicks, this new tool scans your org for simple JavaScript buttons, converts them to point-and-click alternatives, and then deploys everything right to your org.

The Lightning Experience Configuration Converter recreates your org’s JavaScript buttons as Lightning components, quick actions, or other solutions — all without touching your original buttons. Before committing to any changes, you can preview the new component code or declarative steps and verify that the alternatives work as expected.

This tool currently converts some (but not all) JavaScript buttons that implement “url-hacks.” (If you’re not familiar with the term, a “url-hack” is how the community refers to a URL that sets predefined values.) This is the most common use case for JavaScript buttons. The Configuration Converter recreates these buttons as either quick actions, Lightning component actions, or custom buttons or links, based on what the JavaScript code is doing. JavaScript buttons can have varying degrees of complexity. Currently, the tool supports simpler “url-hack” implementations.

Example 1: Let’s look at a few examples of how the Configuration Converter can help Jennifer, a Salesforce developer at Ursa Major Solar, Inc., recreate the JavaScript buttons used in their org.

Ursa’s Salesforce implementation includes a custom JavaScript button that kicks off a Google search for “San Francisco.” The JavaScript for this button looks like this:

window.open(“https://www.google.com/search?q=San%20Francisco”)

When Jennifer uses the Configuration Converter to recreate this JavaScript button, the tool generates a new detail page button that is functionally equivalent and opens the same URL.

Example 2: Ursa’s implementation also includes a JavaScript button that uses a “url-hack” to edit a record and set a predefined value for a field. The JavaScript looks like this:

location.replace(“/0016A00000MlPFl/e?00N6A00000IF4Mo=MyValue”)

When Jennifer runs the Configuration Converter for this button, it creates a Lightning component action that opens a record for editing and sets the field with the ID of “00N6A00000IF4Mo” to “MyValue.”

To get started using the Configuration Converter:

Visit the Lightning Experience Configuration Converter tool and log in with your sandbox or Developer Edition org credentials. Under Settings, list the objects that you want to scan for JavaScript buttons. For performance and manageability, we suggest you scan one object at a time. Click Refresh Buttons. Select Convert to recreate detected JavaScript buttons or Convert and Deploy to recreate detected JavaScript buttons and add the new Lightning alternatives to page layouts. Thoroughly test the changes before deploying to your production org.

This is just the start for the Configuration Converter. We’re looking at ways to extend the tool to help with additional customizations in your org. We look forward to your thoughts and feedback on the Lightning Experience Configuration Converter Trailblazer community group.

Resources