Tweet

Lightning Component Actions with Signature Capture

Introduction

As some readers of this blog may be aware, a year or so ago I wrote a Lightning Component for the Component Exchange that was soon to be launched at Dreamforce. The component is called Signature Capture and unsurprisingly allows a user to capture a signature image and attach it to a Salesforce record. Up until the Winter 17 release of Salesforce, the only way to associate this with a record declaratively was to use the Lightning App Builder to include it in a custom record home page. This works fine but is a slightly odd user experience, as the component is always present even after the user has captured the signature. This all changed once Winter 17 was live thanks to Lightning Component Actions.

Lightning Component Actions

As the name suggests, Lightning Component Actions are custom actions that invoke a lightning component. Many lightning components are called, but few are chosen for custom actions. Specifically those that implement one of two interfaces:

• force:LightningQuickAction

• force:LightningQuickActionWithoutHeader

The difference being that if you implement force:LightningQuickActionWithoutHeader the entire user interface is down to you.

You can use Lightning Component Actions in Salesforce1 and the Lightning Experience.

SignatureCaptureAction

The latest version of Signature Capture package contains a simple component that implements the force:LightningQuickAction interface and includes the Signature Capture component itself. To create a quick action that uses this is a matter of a few clicks. 

Setting Up

First choose which sObject type you want to associate the quick action with - in the screenshots below I’m using account.

Navigate to the Buttons, Links, and Actions section of the setup for the sObject and choose New Action. Select ‘Lightning Component’ as the action type and ‘BGSIGCAP:SignatureCaptureAction' as the Lightning Component. I find that a height of 500px works best, but your mileage may vary. Then enter a Label and Name and click the Save button:

Once the quick action is defined, it must be added to the page layout in the Salesforce1 and Lightning Experience Actions section (if you haven’t added any quick actions to this section before you’ll need to override the default via the link provided):

Take it for a Spin

After setup is complete, navigate to any account record in the Lightning Experience and you will see the quick action in the set of buttons on the top right:

Clicking the button opens the action in its own dialog, allowing a signature to be drawn via mouse, trackpad etc:

To my mind this is a much better user experience, as the component only appears on demand, so there is no confusion around a component that is always present. The slight downside is that once the signature has been captured the user still has to close the dialog via the standard Cancel button, but that’s a minor drawback to my mind.

Mobility Included

Adding the quick action to the page layout also makes it available to the Salesforce1 application on mobile devices. A word of warning around this - the locker service currently doesn’t surface touch events to a component, so if you enable the locker service the Signature Capture component won’t work on tablets or phones.

Repo Man

The Signature Capture component has its own github repo with sample apps (or app at the time of writing!). This is also where feature requests are tracked, so if there’s anything you’d like to see added, let me know and I’ll see if it can be accommodated. Just to set expectation, this is something that I work on mainly in my spare time (I’m currently on vacation, hence having time for this post) so I may take a while to respond.

Related Posts

• Lightning Components, Visualforce and SObject Parameters
• Lightning Component Events - Change Types with Care
• Lightning Component Events
• Lightning Components and Unobtrusive JavaScript
• Lightning Components and Custom Apex Classes
• Lightning Component Wrapper Classes

 Follow @bob_buzzard

 

 

Tweet

Lightning Components - New Tab, New You

Introduction

This is something I’ve been meaning to blog about for a while now, but things like Dreamforce, preparing for Dreamforce and the Winter 17 release kept getting in the way. I didn’t get as far as setting up a nice example, due to the sheer volume of code involved, so I haven’t been back and tried it out recently. Therefore it’s possible that you’ll never have the same experience I did, but as it’s not exactly onerous it seemed worth putting it out there anyway. Your mileage may vary.

Signature move

While building out the MVP for our BrightMedia Lightning booking page to demonstrate at Dreamforce, I needed to change the signature of one of my Apex controller methods, so to get a simple example from something like:

public static Account GetAccount(String idStr)

to

public static Account GetAccount(String idStr, String name)

and changed the parameters that the Lightning Component passed on the action from:

var params={idStr:'0018000001QtQVA', name:'Blog Post Account'};

That went well!

Once I’d made the various changes and saved all the artefacts, I refreshed the page and starting seeing some unexpected behaviour. The name parameter came through as null regardless of what I set it to. Debug statements in the lightning component showed that the name had a value (it wasn’t a hardcoded string unlike the example above!), but some time after I added it to the action it went bad. Making it a hardcoded string didn’t help, nor did juking around the other parameters. I even tried adding more parameters that definitely didn’t exist server side, but nothing helped.

After a some time and about and thousand debug statements later, I found that while I might be adding the new parameter to my params object, when that was sent to the server it had disappeared, hence the server always reported null.

Cache is king

I then tried what I should have as soon as this manifested itself, the browser equivalent of turning it off and on again. I closed the browser tab and opened a new one. Lo and behold everything worked as expected. We all know that the lightning framework aggressively caches on the front end to improve performance, and it looks like the client retained a metadata view of the server side signature after I changed it.

Now I need to stress that for once I’m not complaining about the behaviour of the framework! This is exactly the kind of thing that I’d expect when caching metadata. It’s not always possible to check everything in a cache is still valid - you quickly start to lose the benefit if you go back and check the source on every request. 

The key takeaway here is that when your application involves caching and you change something which doesn’t work as you expected, open a new tab (or window), or even a new browser. It only takes a few seconds and will save time and heartache in the long run.

Related posts

• Deploying Lightning Components - Go Big or Go Missing
• Lightning Component Events - Change Types with Care

 Follow @bob_buzzard

Tweet

Visualforce Development Cookbook Second Edition

Introduction

As regular readers of this blog will know, I wrote a book three years ago - the Visualforce Development Cookbook - and I really haven't stopped banging on about it since. Well things just got worse as I finished the second edition in ?September? and I'm obviously keen to shift as many copies as possible!

What’s a Second Edition?

A second edition isn't a new book. Instead it's an iteration on the previous version, minus content that is no longer relevant and including new features, so the first job is to identify what should be cut and what should be added.

One of the nice things about working on Salesforceis that over time new features are added that remove the need for custom code, so I was able to chop a few recipes out that are now handled natively by the platform. The next job is to update all existing code to the latest API version - something that typically happens several times as Salesforce produces releases faster than I can write a book (even a second edition!). 

Then its back to the writing - for existing recipes making sure that the text is still appropriate and creating new recipes from scratch. This was pretty compressed this time around, as Packt proposed a pretty aggressive timescale to complete before Dreamforce which I was more than happy to sign up to, as I knew that would take up all of my time through to mid-October. I wouldn't recommend this if you don't have some vacation time you can dedicate to writing though, as it would have been pretty tough to complete with only evenings and weekends available.

What’s changed?

The main changes in the second edition are:

• The chapter on Force.com sites has been reworked to use the Salesforce Lightning Design System
• The chapter on jQueryMobile has been replaced with Salesforce1 recipes.
• A new chapter on Troubleshooting has been added, covering debugging, managing the view state and advice on avoiding common problems.
• All the retained recipes have been revised as appropriate.

You want me to buy it again?

Now I’m not like the music industry that expects you to buy the same  music every time they think up a different format, and I can understand that for someone who already purchased the first edition, this might not represent enough of a change to justify buying the second edition (although it was for Fabrice Cathala, who is clearly going for the full set - thanks Fabrice!).

I raised this with the publishers and they gave me a couple of discount codes to use, both valid until 17th October, which you can use on the Packt website:

• Use code VISDSE50 for 50% off the Ebook
• Use code VISDSE15 for 15% off the print book

Note that you don't need to have purchased the first edition to use these codes, you can simply use them to scoop up a bargain.

Show me the code!

For those who just need the code and no explanation, its available free of charge on github at:

 https://github.com/PacktPublishing/Visualforce-Development-Cookbook-2e

A word of advice though - best not come to me asking for help around adapting the recipes or producing unit tests if you've decided not to purchase the book - that would be asking me to cannibalize my own sales!

Related Posts

• Writing a Book
• Visualforce Development Cookbook

 Follow @bob_buzzard

Tweet

Force CLI Part 4 - Deploying Metadata

Introduction

In previous posts in this series I’ve covered Getting Started, Extracting Metadata and Accessing Data via the Force CLI. In this post I’ll cover the functionality that I use probably 95% of the time that I use the Force CLI - deploying metadata from the local filesystem to a Salesforce instance.

The Building Blocks

Like other tools for deploying to Salesforce (e.g. migration tool, Eclipse IDE) there are a two items required to deploy via the Force CLI

Project Manifest (aka package.xml)

The package.xml file defines the metadata components that will be deployed - you can find out more about this in the Salesforce Metadata API Developer’s Guide. 

Metadata Components

The metadata components need to appear in the directory structure expected by the metadata API - e.g. Apex classes in a directory named ‘classes’, Visualforce pages in a directory named ‘pages'

I don’t make the rules (but I do make the deployment directory)

The rule when deploying is that the components specified in the package.xml manifest file need to match those present in the metadata components directory structure. If you specify components that are missing you will get an error, and if you provide additional components that aren’t mentioned in the package.xml, you’ll get a different flavour of error.

My metadata comes from GIT, so the metadata components structure of my entire project is defined there. However, I don’t always want to carry out a full deployment so I create a new structure in a temporary directory and create a package.xml file reflecting that. I also use a naming convention for my temporary directory so that I can look back at the order that I did things in - drop_<YYYYMMDDhhmmss>, where YYYYMMDD is the year/month/day of the date and hmmss is the hours/minutes/seconds of the time. The reason I go with this naming convention is that when I use the ls command, my directories are listed in order of creation:

$ ls -l

drwxr-xr-x  6 kbowden  wheel    204 16 Sep 14:39 drop_20160916141152
drwxr-xr-x  6 kbowden  wheel    204 17 Sep 10:11 drop_20160916184125
drwxr-xr-x  6 kbowden  wheel    204 17 Sep 12:45 drop_20160917121232
drwxr-xr-x  6 kbowden  wheel    204 18 Sep 12:56 drop_20160918092957
drwxr-xr-x  6 kbowden  wheel    204 18 Sep 19:21 drop_20160918185148
drwxr-xr-x  6 kbowden  wheel    204 20 Sep 15:39 drop_20160920152837

To use a very simple example, here’s the directory structure to deploy just the User object. My starting directory is /tmp/drop_20160923080432:

  /tmp/drop_20160923080432/target/objects/User.object
  /tmp/drop_20160923080432/target/package.xml

 My package.xml file just contains an entry to deploy the objects directly (it’s called CustomObject, but covers both standard and custom):

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>*</members>
    <name>CustomObject</name>
  </types>
  <types>
    <members>*</members>
    <name>ApexPage</name>
  </types>
  <version>37.0</version>
</Package>

Deploy all the Metadata

Once the directory structure and manifest are in place, use the force import command to deploy your metadata, using the -d switch to specify the directory containing the metadata:

force import -d /tmp/drop_20160923080432/target

The Force CLI will update you every five seconds on progress

Not done yet: Queued  Will check again in five seconds.
Not done yet: InProgress  Will check again in five seconds.
Not done yet: InProgress  Will check again in five seconds.
Not done yet: InProgress  Will check again in five seconds.
Not done yet: InProgress  Will check again in five seconds.
Not done yet: InProgress  Will check again in five seconds.

Once the deployment is complete, you’ll get details of successes/failures - the default behaviour is simply the to output the number of each

Failures - 0

Successes - 24
Imported from /tmp/drop_20160923080432/target

While if you specify the -v switch, you'll get full details of each success/failure:

Successes - 24
User.DFP_Id__c
	status: unchanged
	id=00N80000005st6iEAA
User.Default_Tab__c
	status: unchanged
	id=00N80000005st6kEAA
User.Department__c
	status: unchanged
	id=00N80000005st6lEAA

   ...

Deploying to Production

As everyone in the Force.com world knows, in order to deploy metadata to production you need to run some unit tests. The Force CLI provides support for this via the -l switch, which takes the same options as the migration tool:

• NoTestRun 
• RunSpecifiedTests
• RunLocalTests
• RunAllTestsInOrg

Verification Only

Another very useful switch is -c. This carries out a verification only deployment and rolls back all changes upon completion. I use this as part of our continuous integration environment to make sure I can successfully deploy to a clean development environment.

Related Posts

• Force CLI Part 1 - Getting Started
• Force CLI Part 2 - Extracting Metadata
• Force CLI Part 3 - Accessing Data

 Follow @bob_buzzard

Tweet

Stand and Deliver with Salesforce Geocoding

Introduction

The Summer 16 release of Salesforce introduced Automatic Geocodes for Addresses which, as the name suggests, allows you to geocode records with addresses automatically. To enable this just go to Setup, type ‘Clean' into the search and click on Clean Rules from the resulting setup nodes.  Then activate one or more of the clean rules and wait a few minutes. Much easier than setting up a batch job to integrate with Google and then finding yourself in breach of the license terms! 

In conjunction with the Geolocation API, this new feature allows you to build some cool applications without too much effort. In this post I’ll show how to combine these two technologies to build an application that assigns a delivery to the nearest user (driver, bike messenger etc) to the collection location.

User Check In

The functionality to allow users to check in (record their location) is provided by a Lightning Component. The component includes the Lightning Design System (yeah, I know it's part of the platform now, but including it myself means that I can also use this component in lightning out) and after the CSS has loaded, uses the geolocation API to capture the current location:

    doInit : function(cmp, ev) {
        var self=this;
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(
                function(result) {self.gotGeoCode(result, cmp, self);},
                self.error,
                {
                maximumAge: 0,
                timeout:30000,
                enableHighAccuracy: true
                }
            );
        }
    },

The parameters passed to the geolocation function are as follows:

• maximumAge - the maximum age of a cached position. Setting this to zero ensures that a new position is captured
• timeout - the maximum number of milliseconds to wait for a response
• enableHighAccuracy - requests that the most accurate position is captured. A request specifying this typically takes longer and consumes more power, and may be denied by the hardware. It’s just a suggestion really.

Once captured, the a server side Apex action is invoked to store the position in a custom field on the user record, along with a timestamp of when it was captured:

    @AuraEnabled
    public static String StoreUserLocation(Decimal latitude, Decimal longitude)
    {
        String result='SUCCESS';
        try
        {
	    User u=new User(id=UserInfo.getUserId(),
    	                    Location__Latitude__s=latitude,
                           Location__Longitude__s=longitude,
            	            Location_Timestamp__c=System.now());
	    update u;
        }
        catch (Exception e)
        {
            result=e.getMessage();
        }
        
        return result;
    }

Note that I don’t need to retrieve the user record from the database to update it, I can just instantiate a new User object in memory and specify the id based on the UserInfo global - always worth saving a SOQL call if possible.

The component in action is shown in the screen capture video below:

Delivery Request

The flip side of the user check in is the delivery request. This is where a customer requires something to be collected from one (their) account and delivered to another. As this isn’t something that is likely to be requested on the fly, this is handled by a Visualforce page, although still using the Lightning Design System to style a Visualforce form.

To create a new delivery, the customer (me in this case) specifies the From and To account and any specific delivery instructions. I’m sending a package to Universal Containers as they seem to have a new social media team and I am keen to engage with them:

The package is being sent from Sea Palling Beach, where myself and the Jobs Admin have recently checked in:

When the record is saved, the controller sets the owner to the user who has most recently checked in to a location within 50 miles - if no such user can be found, the owner will be left as the user that created the record:

 

    public PageReference save()
    {
        Account acc=[select ShippingLatitude, ShippingLongitude
                     from Account
                     where id=:delivery.From__c];
	List users=[SELECT id, Location__c, Location_Timestamp__c
	 	    FROM User
	 	    WHERE DISTANCE(Location__c, GEOLOCATION(:acc.ShippingLatitude, :acc.ShippingLongitude), 'mi') < 50
                    ORDER BY Location_Timestamp__c DESC];
	
	if (users.size()>0)
        {
            delivery.OwnerId=users[0].id;
        }
        
        insert delivery;

        ApexPages.StandardController std=new ApexPages.standardController(delivery);
        return std.view();
    }

 So even though I created the delivery request, it was assigned to the job admin user as they checked in more recently:

That’s It?

That is indeed  all there is to it - a couple of custom fields on the user object, a custom object, one lighting component, one Visualforce page and two Apex classes. If you are so inclined, you can view the full code at the github repository. 

 Follow @bob_buzzard

Tweet

Force CLI Part 3 - Accessing Data

Introduction

In part 2 of this series, Extracting Metadata, I covered how to extract configuration data from your Salesforce instance, which it is something pretty much every other deployment tools offer. A key difference of the Force CLI is that you aren’t limited to configuration - you can retrieve and update your Salesforce data from the command line or a script. Very useful if you have to carry out some data migration as part of a deployment for example.

NOTE: In the examples below the commands are split over multiple lines for readability, but should be entered on a single line if you are trying them out for yourself.

Executing SOQL

The command for executing SOQL is force query, followed by the SOQL string enclosed in quotes:

> force query "select id, Name, Industry from Account 
               order by CreatedDate  limit 5"

The default format is ascii table style:

 Id                 | Industry       | Name
--------------------+----------------+---------------------------------
 0018000000Q9v1VAAR | Construction   | Pyramid Construction Inc.
 0018000000Q9v1WAAR | Consulting     | Dickenson plc
 0018000000Q9v1XAAR | Hospitality    | Grand Hotels & Resorts Ltd
 0018000000Q9v1YAAR | Transportation | Express Logistics and Transport
 0018000000Q9v1ZAAR | Education      | University of Arizona
 (5 records)

which is fine for displaying data on the screen, but not that easy for processing. Luckily the output format can be changed via the -format switch.

CSV Formatting

Specifying csv as the value of the format switch outputs the results of the query in the familiar comma separated format, along with a list of headers:

> force query "select id, Name, Industry from Account 
               order by CreatedDate  limit 5" -format:csv

"Id","Industry","Name"
"0018000000Q9v1VAAR","Construction","Pyramid Construction Inc."
"0018000000Q9v1WAAR","Consulting","Dickenson plc"
"0018000000Q9v1XAAR","Hospitality","Grand Hotels & Resorts Ltd"
"0018000000Q9v1YAAR","Transportation","Express Logistics and Transport"
"0018000000Q9v1ZAAR","Education","University of Arizona"

 while this is more useful for processing, it doesn’t work well with subqueries:

 
> force query "select id, Name, (select id, FirstName from Contacts) 
               from Account order by CreatedDate limit 5" -format:csv

"Contacts","Id","Name"
"[map[Id:0038000000asT8TAAU FirstName:Pat]]","0018000000Q9v1VAAR","Pyramid Construction Inc."
"[map[Id:0038000000asT8UAAU FirstName:Andy]]","0018000000Q9v1WAAR","Dickenson plc"
"[map[Id:0038000000asT8VAAU FirstName:Tim] map[Id:0038000000asT8WAAU FirstName:John]]","0018000000Q9v1XAAR","Grand Hotels & Resorts Ltd"
"[map[Id:0038000000asT8ZAAU FirstName:Babara] map[FirstName:Josh Id:0038000000asT8aAAE]]","0018000000Q9v1YAAR","Express Logistics and Transport"
"[map[Id:0038000000asT8bAAE FirstName:Jane]]","0018000000Q9v1ZAAR","University of Arizona"

JSON Formatting

Specifying json as the format switch outputs the result in JavaScript Object Notation:

force query "select id, Name, (select id, FirstName from Contacts) 
             from Account order by CreatedDate limit 5" -format:json
 

[{"Contacts":{"done":true,"records":[{"FirstName":"Pat","Id":"0038000000asT8TAAU","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8TAAU"}}],"totalSize":1},"Id":"0018000000Q9v1VAAR","Name":"Pyramid Construction Inc.","attributes":{"type":"Account","url":"/services/data/v36.0/sobjects/Account/0018000000Q9v1VAAR"}},{"Contacts":{"done":true,"records":[{"FirstName":"Andy","Id":"0038000000asT8UAAU","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8UAAU"}}],"totalSize":1},"Id":"0018000000Q9v1WAAR","Name":"Dickenson plc","attributes":{"type":"Account","url":"/services/data/v36.0/sobjects/Account/0018000000Q9v1WAAR"}},{"Contacts":{"done":true,"records":[{"FirstName":"Tim","Id":"0038000000asT8VAAU","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8VAAU"}},{"FirstName":"John","Id":"0038000000asT8WAAU","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8WAAU"}}],"totalSize":2},"Id":"0018000000Q9v1XAAR","Name":"Grand Hotels \u0026 Resorts Ltd","attributes":{"type":"Account","url":"/services/data/v36.0/sobjects/Account/0018000000Q9v1XAAR"}},{"Contacts":{"done":true,"records":[{"FirstName":"Babara","Id":"0038000000asT8ZAAU","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8ZAAU"}},{"FirstName":"Josh","Id":"0038000000asT8aAAE","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8aAAE"}}],"totalSize":2},"Id":"0018000000Q9v1YAAR","Name":"Express Logistics and Transport","attributes":{"type":"Account","url":"/services/data/v36.0/sobjects/Account/0018000000Q9v1YAAR"}},{"Contacts":{"done":true,"records":[{"FirstName":"Jane","Id":"0038000000asT8bAAE","attributes":{"type":"Contact","url":"/services/data/v36.0/sobjects/Contact/0038000000asT8bAAE"}}],"totalSize":1},"Id":"0018000000Q9v1ZAAR","Name":"University of Arizona","attributes":{"type":"Account","url":"/services/data/v36.0/sobjects/Account/0018000000Q9v1ZAAR"}}]

 suitable for processing by a myriad variety of tools.

Prettified JSON

For the best of both worlds - JSON formatted for automated processing but laid out so that humans can read it, specify json-pretty as the format switch:

> force query "select id, Name, (select id, FirstName from Contacts) 
                        from Account order by CreatedDate limit 5" -format:json-pretty

[
  {
    "Contacts": {
      "done": true,
      "records": [
        {
          "FirstName": "Pat",
          "Id": "0038000000asT8TAAU",
          "attributes": {
            "type": "Contact",
            "url": "/services/data/v36.0/sobjects/Contact/0038000000asT8TAAU"
          }
        }
      ],
      "totalSize": 1
    },
    "Id": "0018000000Q9v1VAAR",
    "Name": "Pyramid Construction Inc.",
    "attributes": {
      "type": "Account",
      "url": "/services/data/v36.0/sobjects/Account/0018000000Q9v1VAAR"
    }
  }
    <removed for clarity>
]

Working with Records

If you know the ID(s) of the records you need to work with, the force record command allows you to access and manipulate record instances.

Retrieving Records

To retrieve a record, execute force record <type> <id> - this brings back all fields :

> force record get Contact 0038000000asT8TAAU

AccountId: 0018000000Q9v1VAAR
AssistantName: Jean Marie
AssistantPhone: (014) 427-4465
Birthdate:
CreatedById: 00580000001ju2CAAQ
CreatedDate: 2009-04-19T11:27:45.000+0000
Department: Finance
Description:
Fax: (014) 427-4428
FirstName: Pat

 <removed for clarity>

SystemModstamp: 2013-01-10T16:17:39.000+0000
Title: SVP, Administration and Finance
attributes:
  type: Contact
  url: /services/data/v36.0/sobjects/Contact/0038000000asT8TAAU

Updating Records

To update a record, execute force record update <type> <id> <field>:<value> : 

> force record update Contact 0038000000asT8TAAU FirstName:"Patrick"

Record updated

I can then confirm that the record has been updated by retrieving it again and extracting the FirstName field:

>force record get Contact 0038000000asT8TAAU | grep FirstName

FirstName: Patrick

(the grep command extracts any lines in the output containing the search term, FirstName in this case.

Creating Records

You aren’t just limited to existing records with the Force CLI - you can also created them, either individually on en-masse from a file.

To create a single record execute force record create <type> <field> <field> … :

> force record create Contact FirstName:"Keir" LastName:"Bowden"

Record created: 00380000023TUCxAAO

> force record get Contact 00380000023TUCxAAO

AccountId:

 <removed for clarity>

FirstName: Keir
LastModifiedById: 00580000001ju2CAAQ
LastModifiedDate: 2016-07-16T10:48:38.000+0000
LastName: Bowden

 <removed for clarity>

To create multiple records execute force record create:bulk <type> <file> - the default format is CSV, but you can specify the content type of the file if it is different. Thus the following file, named contacts.csv:

"FirstName","LastName"
"First","CLI Blog"
"Second","CLI Blog"
"Third","CLI Blog"

can be loaded as follows

> force record create:bulk Contact contacts.csv

Batch 1 of 1 added with Id 75180000006NK0pAAG
Job created ( 75080000004fh7wAAA ) - for job status use
 force bulk batch 75080000004fh7wAAA 75180000006NK0pAAG

and I can verify the load using the query command introduced earlier

> force query "select FirstName, LastName from Contact where LastName ='CLI Blog'"

 FirstName | LastName
-----------+----------
 First     | CLI Blog
 Second    | CLI Blog
 Third     | CLI Blog
 (3 records)

Related Posts

• Force CLI Part 1 - Getting Started
• Force CLI Part 2 - Extracting Metadata

 Follow @bob_buzzard

Tweet

Force CLI Part 2 - Extracting Metadata

Introduction

In Part 1 of this series, Getting Started, I covered downloading and installing the Force CLI, and logging in to Salesforce. This post covers extracting metadata from your Salesforce org.

Why do I need the Metadata?

This is a very good question - a lot of the time the answer is that you don’t. If you do, its highly likely that your IDE of choice will handle this for you - pulling down the metadata components that you are working on and uploading the changes when you save or deploy. The classic use case for this is to make a backup of your implementation, typically on a regular schedule in an unattended fashion.

EXTRACT ALL THE METADATA

At first glance, this looks about as straightforward as it could be. Executing force help shows there is a command that looks tailor made:

export    Export metadata to a local directory

By default, this command dumps the metadata to a subdirectory of your current directory named (fittingly enough) metadata, although you can supply a different location for the output as an additional parameter.

After logging in, I can export the metadata by executing the following command:

force export

However, at the time of writing this doesn’t quite bring everything back. Here’s the contents of my metadata directory- spot the deliberate mistake: 

analyticSnapshots	homePageComponents	quickActions
applications		homePageLayouts		remoteSiteSettings
approvalProcesses	labels			reportTypes
assignmentRules		layouts			roles
autoResponseRules	networks		samlssoconfigs
callCenters		objectTranslations	scontrols
classes			objects			sharingRules
communities		package.xml		sites
components		pages			staticresources
connectedApps		permissionsets		tabs
dataSources		portals			translations
flows			profiles		triggers
groups			queues			workflows

Spotters Badge for those eagle-eyed readers that wondered where the Lightning Components metadata directory(aka aura) is.

There’s currently no way to influence the metadata elements that are included by the export command, but luckily there is a mechanism to extract individual metadata component types.

Fetch! Good boy!

The fetch subcommand provides granularity around metadata extraction, not just down to a single type of metadata, but as far as a single metadata component. I’m not going down to that level, but if you are interested then execute force help fetch which gives full details of the options.

The fetch command takes a -t switch to identify which metadata type you want to extract. For all types you can specify the name of the metadata type as detailed in the Metadata API Developer’s Guide, so to extract the Force.com Sites metadata, for example, you would execute:

force fetch -t CustomSite

The metadata name for Lightning Components is AuraDefinitionBundle, but you can also specify Aura as the type, which will extract the Lightning Component metadata via the REST API - I tend to use the latter version as I find it is slightly faster than the metadata route.

Executing 

force fetch -t Aura

extracts the Lightning Components to the metadata directory, and the entire Salesforce configuration is now in one place:

analyticSnapshots	homePageComponents	remoteSiteSettings
applications		homePageLayouts		reportTypes
approvalProcesses	labels			roles
assignmentRules		layouts			samlssoconfigs
aura			networks		scontrols
autoResponseRules	objectTranslations	sharingRules
callCenters		objects			sites
classes			package.xml		staticresources
communities		pages			tabs
components		permissionsets		translations
connectedApps		portals			triggers
dataSources		profiles		workflows
flows			queues
groups			quickActions

Putting these commands together in a bash script, with a dash of compression, gives me a handy backup file containing my metadata:

#/bin/bash
force login
force export
force fetch -t Aura
zip -r metadata > backup.zip

Note - if you run the above commands directly from the command line, ignore the first one. That tells the OS which command to use to execute the script, which makes no sense for individual commands.

Version Control to Major Tom

Where this can be particularly powerful is if you integrate with version control.  You can use a script to periodically extract the latest metadata and merge into your Git repository for example.

Related Posts

• Force CLI Part 1 - Getting Started

 Follow @bob_buzzard