The New Code Quality Report

Snapshot has an amazing new Code Quality Report that can identify many common programming flaws in any Apex Class. You can schedule the Code Quality Report to run after any Snapshot and send a PDF, CSV, or HTML file to admins or developers with all of the various problems that were found. Super admins can even set up a Code Quality Gateway to prevent selected programming problems from being deployed to any org! Let’s dig in and take a look at this new capability.

Installing PMD

The Code Quality Report uses the PMD open source static code analyzer. Nobody is really sure what PMD stands for, but this is the gold standard for analyzing Apex code and finding common programming flaws. The open source PMD project is the foundation for most of the code quality systems available on the Salesforce platform. You will need to be sure that PMD is installed on your local machine. Snapshot uses PMD through the command line interface. PMD is a Java application, so you will also need to be sure that Java is installed, if it is not already. You can learn more about PMD here:

https://pmd.github.io/

We have simplified the PMD installation process as much as possible. The first tab of the Apex Code Quality dialog has a button at upper right called “PMD Connection.” Click that button, and there will be various links and information about how to install PMD. When you are ready, click the “Test Installation” button, and Snapshot will tell you if PMD is installed or not. You can also return to this screen and update the version of PMD that you are using. The path to the current version is in the pathname above the button.

Apex Code Quality

Once PMD is installed, you can right-click any Snapshot item and select “Apex Code Quality” from the popup menu. You can also use the Options Menu at the top of the screen. The dialog below will appear, and you can see all of your Apex Classes at left. Click on any class name and the middle section will show you various problems with the code. You will see the Rule Set and Rule that was violated. Scrolling to the right, the report details the seriousness of the problem, the impacted line numbers, and a detailed explanation of how to fix the issue. Click on any rule and the lines of code that are causing the problem will be highlighted at right.

This first tab provides an easy way to quickly preview all of your Apex Classes and review any code problems. You can click down the list of issues and see all of the affected lines of code at right. Right-click the center table to export all of the problems as a CSV, HTML, or PDF file. If you check multiple Apex Classes at left, then all of the selected items will be included in the final report under the middle tab.

Understanding Quality Results

PMD divides code quality problems into seven categories:

  • Best Practices
  • Code Style
  • Design
  • Documentation
  • Error Prone
  • Performance
  • Security

Each category contains different rules. There are about 45 different rules that PMD uses to analyze Apex code. A full description of each rule is documented in the Snapshot interface. Each rule is assigned a number between 1 (highest priority) and 5 (lowest priority). The priority numbers for each rule can be assigned in the Snapshot interface. In this manner, you can decide what rules are the most critical or least important. Rules can also be removed from consideration completely if desired.

  • Priority 1) Change Absolutely Required
  • Priority 2) Change Highly Recommended
  • Priority 3) Change Recommended
  • Priority 4) Change Optional
  • Priority 5) Change Highly Optional

Managing Code Quality

Right-click the center report on the first tab or click the “Manage Quality” button on the second tab to assign each of the available rules a priority. In the example below, we have assigned rules regarding Code Style and Best Practices to be optional, while rules regarding Security and Performance are absolutely required. If there are some rules that you would like to ignore entirely then uncheck the “Include Rule in Report” checkbox.

Automating Code Quality

Just like other reports in Snapshot, you can schedule and automate the Code Quality Report. In the last tab, select the event to trigger the report, and then send a PDF, CSV, or HTML file to an email list or Chatter group. Alternatively, the report could be saved to Salesforce Content or a local folder. Code Quality Reports can be conditional, and only sent out if changes are required in the code. In this manner, any org can be monitored for code quality, and a full report is generated and delivered if there are problems.

Conclusion

There you have it. Snapshot now has a state-of-the-art code quality analysis and monitoring system. Be sure to give this new feature a try and let us know how it works for you.


Introducing Data Migration For Snapshot

Metazoa has added some powerful new tools to Snapshot that move connected sets of data between Salesforce orgs. This capability is useful for backing up data, refreshing Sandboxes, merging orgs, and populating orgs with test data. Now Snapshot can move metadata to a destination org and follow up by migrating the actual data as well. Both of these transactions can be scheduled as needed.

When records are migrated between orgs, all of the internal relationships are preserved. External references in the Dataset are also connected to matching objects on the destination. You can also select the fields used for matching destination objects. For example, you might want to match Accounts by Name and BillingCity.

There are capabilities to map objects and fields to new names, and to scramble fields to obscure personal or financial information. You can also import Datasets from other systems with CSV files. Our new CSV file format provides a simple way to import, merge, and connect data to any destination org.

Snapshot uses the Salesforce Bulk API for this new feature to ensure that very large Datasets can be moved efficiently. We have tested Snapshot by moving hundreds of thousands of records. This blog presents an overview on how to build and migrate Datasets. Find more detailed technical documentation here:

https://www.metazoa.com/publications/dataset_migration_v3.pdf

Getting Started

Simply restart Snapshot and you will automatically get the new Data Migration capability. When you right-click a Deployment Arrow, the second set of options will have new commands to Build, Import, and Migrate Datasets. If you do not see these commands, then perhaps the Deployment Arrow is connected to a Developer Project. They do not have any actual data and cannot be used as a source of data or as a destination for migration.

The option to Build a Dataset will use the source Salesforce org to download multiple records in the form of XML files to your local machine. The option to Import a Dataset will use CSV files from any source to create a new Dataset as well. Lastly, the option to Migrate a Dataset will insert and update records from the selected Dataset into the destination Salesforce org.

Building Datasets

The first tab of the Build Dataset dialog allows you to select parent objects that you want to include in the Dataset. These records are available on the source Salesforce org. You can select all records, a subset of records by name, or a subset of records using a complex filter. The total number of downloaded records can be limited. This is useful for grabbing a random subset of records for acceptance testing or application development.

Selecting Children

The next tab allows the selection of connected child objects for each parent object. When a Dataset is created, the selected parent records are loaded first, followed by all of the children connected to that parent. You can specify multiple child objects in a hierarchy. The relationship field used to associate each parent and child is shown in parenthesis. The internal relationships between parent and child are always preserved when the Dataset is migrated.

Loading Fields

After that, you can select fields to load for each parent and child object. You can choose fields that need to be loaded by moving them to the list at right. Fields that cannot be created or updated on the destination do not usually need to be loaded. Removing unwanted fields makes your Dataset smaller in size and easier to migrate.

Build Datasets Button

The next tab allows you to enter the name of a new Dataset and then click the Build Datasets button at right to start the download process. All of the download results will be listed in the window pane at lower right. The Dataset will be saved in XML files to your local machine. Snapshot is an extremely secure solution, because we never move your data or metadata to any third-party cloud or Salesforce org! The last tab allows you to schedule the creating of a Dataset at a specific time in the future or as a recurring event.

Importing Datasets

There is another way to create a Dataset. The Import Dataset command is right under Build Datasets when you right-click a Deployment Arrow. When you Import a Dataset, you can select any number of CSV or XML files and add them to the list at left. The interface will show the imported fields and source records in the window panes at right.

Snapshot has introduced a new CSV file format that simplifies the process of merging and connecting CSV data with any destination Salesforce org. Check out our technical documentation for all of the details on how to prepare CSV files in this format:

https://www.metazoa.com/publications/dataset_migration_v3.pdf

Mapping Fields

The Mapping Fields tab provides an easy way to make sure that the imported object and field names match up to the object and field names in the destination org. First, select the desired destination object name at top. Then go down the list and select matching field names. The same technique applies to matching external references and fields.

Finish Importing

The last tab allows you to enter the name of a new Dataset and then click the Import Datasets button at right to start the import process. If you select an existing Dataset name from the menu then that Dataset will be replaced. When you want to migrate that data to an actual Salesforce org you will need to use the Migrate Dataset dialog, explained in the next section.

Migrating Datasets

After a Dataset has been created, you are ready to migrate these records to a destination Salesforce org. Right-click a Deployment Arrow that is connected to the correct destination org and select the Migrate Datasets option to get started. The Migrate Datasets dialog allows you to select any of the global Datasets from the list at left and see the objects and fields that are available in the list at right.

Matching Fields

Snapshot lets you select the fields used to match records on the destination org. One powerful way to match destination objects is with External Ids. Other common matching fields include object names, email addresses, and usernames. Some Salesforce sandboxes have the same Ids as production orgs. In that case you can simply use the Id field for matching destination objects.

Scrambled Fields

Datasets are often used to move records into a Salesforce Sandbox or Developer Edition for testing or application development. In these situations, you may want to scramble data records that contain sensitive information. These fields might contain financial information, such as credit cards or bank accounts, or personal information, such as email addresses or Social Security numbers. The Scramble Fields tab provides an easy way to select fields that you want to obscure in the destination org.

Deactivate Assets

When a Salesforce record is inserted or updated, various Apex Triggers, Workflow Rules, and Validation Rules might be invoked. These automated behaviors can cause potentially undesirable effects during data migration. For example, thousands of emails might be sent out, or some records might not be updated. The Deactivate Assets tab provides an easy way to deactivate Apex Triggers, Workflow Rules, and Validation Rules in the destination org before data migration is attempted. After migration, the deactivated triggers and rules will be turned back on.

Migrate Datasets Button

The next tab has the main interface for migrating datasets to the destination org. First, make sure that the migration options are set correctly. Then click the Migrate Datasets button to get started. If any errors are encountered, they will be written to the Log Files along with the Salesforce record Ids.

There You Have It!

We are stoked that Snapshot can handle Datasets as well as Metadata. This is a great new product addition. Please give this capability a test drive and let us know how Datasets are working for you.

Register for our Webinar on December 12th at 10:00 a.m. PST to see it in action.


Salesforce User Group Roundup

I've started traveling the country talking to Salesforce Developers and User Groups. Salesforce is in an interesting transition from great product to full-fledged Enterprise Platform. This is a great opportunity for ISV's and Salesforce Administrators alike to build some insanely great new applications that leverage these new capabilities. Everybody is curious about the role of Salesforce DX, and how we used Salesforce DX to supercharge Snapshot 2.0 Change and Release Management.

My talk starts with a discussion about the platform transition at Salesforce, and the role of Salesforce DX. Next, I show some command line examples about how to create a Scratch Org and Push and Pull source from a Developer Project. Many of the new SFDX capabilities were used to create Snapshot as well. Developer Projects can be downloaded from any repository, the files can be harvested, and then turned into a snapshot. Scratch Orgs and Dev Hubs can be connected to your Snapshot Workflow. Support for Second-Generation Packages is on the way, and Developer Controlled Packages can be pushed between Orgs.

Boston Salesforce Developers Group

Salesforce DX: Quick Start, App Development Model, and Continuous Integration

Our intrepid host, Bing Wang, taught a hands-on developer workshop all about using the Salesforce DX Command Line. He covered the lion's share of Salesforce DX capabilities in just about an hour. After that, I spoke about how we used Salesforce DX to connect Source-Driven Development to the Change and Release Process. Thanks for the invitation Boston! We'll see you guys again at DreamForce this year.

Kansas City Salesforce User Group

Next up I visited the Kansas City Salesforce User Group. The audience consisted of Salesforce Administrators, Salesforce Developers, and Power Users. The Kansas City area has a thriving Salesforce community, and this was great to see in person. Our host Dale Zeigler led a lively and wide-ranging discussion about many aspects of Salesforce development. My talk was well received, and there were quite a few questions about how we used Salesforce DX for application development and Change and Release Management.

-----

PRESENTATION

Salesforce is at an inflection point moving from application to platform. This is a great opportunity for ISV developers who want to build new products and enterprise architects who want to tackle new initiatives. Salesforce DX is a key part of this strategy, providing a source-driven programming environment and better organization of developer projects with second-generation packages.

Bill Appleton wrote the first AppExchange application DreamTeam in 2005, and one of the most popular administrative tools Snapshot in 2006. Now working on Snapshot 2.0, Bill will show how he used Salesforce DX to harvest developer repositories and allow administrators to create scratch orgs on the fly. Working together, Snapshot and Salesforce DX connect developer projects to the change and release management process.

BIOGRAPHY

Bill Appleton is a leading expert on the use of web services for smart client applications. He has designed and written approximately three dozen professional software publications, including the first rich media authoring tool World Builder in 1984, the ground breaking multimedia programming language SuperCard in 1989, the worldwide best selling CD-ROM Titanic in 1996, the first AppExchange application DreamTeam in 2005, and the first API Automation Platform DreamFactory in 2010, and Snapshot 2.0 Change and Release Management for Salesforce in 2018.

Bill previously served as the President of the gaming company CyberFlix where he worked closely with Disney, Paramount, Viacom, and Bandai. After that, he was the President of DreamFactory Software, which developed an open source REST API platform for HTML5 and native mobile applications. Currently, he is the CTO at Metazoa building the world's best change and release management application for the Salesforce ecosystem. Many leading computer publications and mainstream magazines have featured Bill’s work, including People Magazine, Newsweek, and US News and World Report.

Specialties: web services, authoring tools, smart clients