Salesforce Archives - Michael Soriano

Simple CICD for Salesforce using SFDX and GitHub Actions

Michael Soriano — Sat, 16 Jul 2022 20:18:23 +0000

I’ve been building Salesforce applications for some time now and we’re always faced with the same struggle when in comes to CICD. See, we write code locally in our machines. Then we use SFDX to push to our sandboxes – this is so we can see the changes, as well as other users test what we’ve built. We commit to Git for storing our code, branch and merge changes. With VSCode, and extensions – this is working fine and as intended.

View in GitHub

TL;DR – if you want to just get to the solution, simply click button above.

The Struggle

The problem lies when we want to deploy our code to the upper environments like UAT and Production. We use a tool called Copado, which takes the code from a designated Sandbox and deploys it. It doesn’t take it from the repository where we originally store our code.

So the developers would have to go to the Copado UI – “re-select” the files that have been modified, choose the Test(s) to run – validate, get it approved and then it pushes it to the orgs. It’s a very slow process. In addition, when one thing fails, you get to start all over again.

This design aims to solve all of that. Note that this solution is based on Pablo Gonazales’ solution – with a few tweaks of my own. I’ve also simplified the model greatly – as you’ll see below.

Modular Repos, 2 Branches

This model is designed for repositories that are “Project” based. So each repository ONLY has the components needed for the application to work. We are NOT deploying all metadata inside an org. It is designed to be small, modular and deployable.

You can trim down your project by selecting only your application’s files – by updating your package.xml in your local SFDX project. I recommend using this extension for VSCode.

In addition, we only really have 2 branches: 1) The “feature branch” – which is the bug fix or the feature the developer is currently working on, and 2) master – which is where all the changes are merged into.

So this is a way simplified version – compared to Pablo’s original solution. The steps for the workflow is as follows:

Create a Feature branch from Master – every time a bug or a feature is added, a developer copies master and works on their own branch. All commits / pushes to this branch stays here (and their personal org) – which they deploy to using SFDX
When changes are good – they open a Pull Request to master. This deploys to the orgs (including UAT)
When everything is tested – PR is closed (merged to master). This deploys the code to production

Again, this is a simplified version. For a more robust workflow – I suggest using Pablo’s design.

GitHub Actions is the glue

As mentioned above, when we code locally – we continuously deploy to our sandboxes all day. This is made possible by SFDX. Now, how do we tie this process in with CICD? That’s where GitHub Actions come in.

It’s basically the thing that ties the two together.

name: Deploy to Production
on:
    pull_request:
      branches: [ master ]
      types:
        - closed
      paths:
        - 'force-app/**'
       
jobs:
    push-to-prod:
        runs-on: ubuntu-latest       
            - name: 'Put changed files into a dir'  
              run: | 
                  mkdir changed-sources
                  sfdx sgd:source:delta --to "HEAD" --from "HEAD^" ...
            - name: 'Deploying to production'
              run: sfdx force:source:deploy -p "changed-sources/force-app" ...
...

As you can see from the sample code above, we’re running SFDX inside Github – as if it was running in our local machine. In addition, we can run npm, node and bash – for things like file manipulation etc.

Features

Only deploy the changed files. Just like in Pablo’s solution – we’re only deploying files that have been changed from master. This keeps the deployment small and fast.

We have the ability to select test classes, or if we leave the default “all” – it will automatically detect test classes in your repo and run them. This logic is inside a file called “parseTests.js” which just looks at all Apex classes that ends with “Test”.

Code Scanning – this part has been commented out in the push-to-orgs.yml – but I strongly suggest using it. This scans the code for best practices and vulnerabilities.

All interactions are done in the repo. No need to use external tools like Jenkins or Copado. We’re using Pull Requests as the basis of whether it gets deployed to the orgs and production.

Git is the source of truth. Unlike Copado – this solution keeps the truth in the Git repo.

How to Use

The repo contains a sample SFDX project. Simply clone and open in VSCode to edit. You will notice a package.xml file – which dictates the files that’s part of the project.

Also inside the .github/worfklows folder are 2 files: push-to-orgs.yml and push-to-prod.yml. These are the actions. This is how we tell GitHub what to do when specific actions are triggered. In our case, its when pull requests are opened, synchronized and closed on the master branch.

You’re going to deploy to 3 orgs in total. So you’ll need to create 3 Action Secrets inside your repo settings.

These correspond to the orgs that you want to deploy to. To create the auth url run the command below:

sfdx force:org:display -u  --verbose --json > auth.json

This will produce a file called auth.json. Inside it is the URL that you need to plug in the repository secrets. You have to do this per org that you want to deploy to.

Once all of the setup is complete, simply create a branch from master and check it out. Open an Apex Class and edit. Stage the file, commit and push.

Now – open a Pull Request. This will trigger the job push-to-orgs.yml.

Note that you don’t have to select any files, or test classes (although that option is available).

Also, any changes to the existing feature branch will trigger this job. Basically as long as the Pull Request hasn’t been closed – you are able to sync your changes as well as deploy automatically.

Once all is good – you can simply close the PR and it will run push-to-prod.yml – which just pushes it to your production org.

The post Simple CICD for Salesforce using SFDX and GitHub Actions appeared first on Michael Soriano.

Environment Variables in Custom Metadata Types

Michael Soriano — Sat, 23 Apr 2022 18:35:54 +0000

Developing custom solutions for Salesforce has some challenges. One of them is having Environment Variables for your application, that can be deployed from org to org without having to change them. We’ve been using Custom Metadata Types (CMT), but once it get to another environment such as production, we end up having to change it. This is basically hardcoding it – which is bad.

What I want is something like an .ini file, that has the environment (org) and key values like below:

[orgname1]

key1=val1
key2=val2
...

[orgname2]

key1=val3
key2=val4
...

This basically can get deployed to any org, and it will just dynamically map to the right set of key values.

Why not use Custom Settings?

So custom settings are independent from org to org. This sounds like the perfect solution for our scenario. But I want something in 1 file – similar to .env files in Node. One that I can include in the SFDX project and get deployed. I believe deploying custom settings – will deploy the same records (unless you do something like below).

Why not YAML or JSON?

I found that INI format is easier for admins to edit. All they have to worry about is grouping by orgs (enclosed in brackets) and immediately following are key value pairs separated by a new line. Note that the format is key=val.

In addition, YAML and JSON requires additional rules such as spaces, tabs, curly braces and commas, and the CMT editor is hard to work with when it comes to formatting. Again, INI format is easier for admins.

I also chose CMT – because its a bit more secure and flexible to work with. You can also use a static file (static resource) or an object. But I don’t want an important file just sitting in a pool of static resources, as well as waste a SOQL call for the later.

Setup the Custom Metadata Type

First step is to create the CMT. Click create a new custom metadata type, fill in the fields and hit “Save“. I chose the name “LS Setting“, so we can store other records in this CMT.

Now add a custom field. This will store the actual contents of our file. Click on “New Custom Field” and fill in the fields. Use a Text Area Long type for this field. I named ours “Value“.

Now let’s enter a record. Name it whatever makes sense to you – in our case, its “Environment Variables” and for the “Value” – add our INI content and click “Save”.

Simply replace the highlighted parts with your org names, enclosed in brackets.

Parsing the Variables with Apex

So this is the fun part. We have a file that we can deploy – we simply have to write the logic that looks in this file and get’s the correct value that we need.

First, I want two static methods that I can use in combination with each other, to produce the desired results:

//first method:
// can return a list of all key value pairs for the org
getEnvVars(null); 
// returns a list with just the string value for spec key passed
getEnvVars('key1'); 

// second method: 
// can be used to get just 1 value 
getEnvVar('key1', envVars);

The purpose of the second method Class.getEnvVar(‘key1’, envVars); is so that we can use it in a class multiple times, without having to parse again and again. We can get the 2nd parameter by running the first method in the class constructor or something like that.

The getEnvVars() method

Let’s build the core of the parser here. So we need to go through each line of the file and put them in the necessary maps and lists. Let’s built the method shell and add the data structures:

public static List getEnvVars(String key){
    List result = new List(); //final result
    Map> rawMap = new Map>(); //temp store
    List envIndexes = new List(); //indexes of our orgs
    List nodeIndexes = new List(); //indexes of key=values

    //logic here...



    return result;
}

I guess it would also help to grab the CMT. Add this in our function:

List settings = [SELECT Value__c FROM LS_Setting__mdt WHERE DeveloperName = 'Environment_Variables'];
String metaData = settings[0].Value__c;

Then let’s do a split on metadata. Let’s also remove the duplicates and populate the envIndexes and nodeIndexes in one go.

List rawList = new List();
for(String str : metaData.split('\n')){ //REMOVES EMPTY LINES...
   if(String.isNotBlank(str)){
      rawList.add(str);
   }
}
Integer index = 0; 
for(String str : rawList){
  if(str.startsWith('[')){ //AN ENVIRONMENT
     envIndexes.add(index);
  }else if(str.contains('=')){ //A NODE KEY/VAL has to have an '='
     nodeIndexes.add(index);
  }
  index++;
}

Now let’s go through our lists of environment and node indexes, and build the rawMap map. One thing to note here, we have 2 arrays of indexes, and a rawList of values. See below:

// rawList [node1,kv1,kv2,kv3,node2,kv4,kv5,kv6]
// envIndexes [0,4]
//             0 1
// nodeIndexes [1,2,3,5,6,7]
//              0 1 2 3 4 5

So rawList is flat, and we have the arrays of indexes, so we can get the values of each item in rawList according to the indexes. Also, we determine which org they belong to by doing a < and > comparison to the next environment index.

for(Integer y=0; y nodes = new List();
               for(Integer x=0; x envIndexes[i]){
                          nodes.add(rawList[nodeIndexes[x]]);
                       }
                   }else{ //not last index
                       if(nodeIndexes[x] > envIndexes[i] && nodeIndexes[x] < envIndexes[i+1] ){
                          nodes.add(rawList[nodeIndexes[x]]);
                       }
                   }                            
                }       
     String env = rawList[envIndexes[i]];     
     env = env.replace('[','').replace(']','').toLowerCase().trim();
     rawMap.put(env,nodes);
     }
  }
}

Finally, let’s build the result – depending on the environment, and if there is a key parameter or not

String curOrg = URL.getSalesforceBaseUrl().getHost(); 
List envVars = rawMap.get(curOrg);

if(key == null){
   result = envVars;
}else{
   result.add(Class.getEnvVar(key,envVars)); //we haven't built this yet...
}

The getEnvVar() method

This one is a small method that we use above – but we can also call in our other classes.

 public static String getEnvVar(String key, List envVars){
    String result = ''; 
    for(String ev : envVars){                 
       if(ev.startsWithIgnoreCase(key)){
          List temp = ev.split('=');
          if(temp[1] != null){
             result = temp[1];
          }
        }                
      }
    return result;
 }

Now we can use the two methods anywhere in our project where we need environment variables.

Don’t forget to include this in your SFDX project using VSCode, I recommend using SFDX PackageXML generator – so you can select the custom object (custom metadata type), custom field and the actual record that you’ve created. This makes it so that you can commit to your repo using GIT and deploy to any org of your choice.

Improvements

Of course this code can be improved drastically. One thing I can think of is having a “default” org fallback. This is so that you don’t have to replicate entire blocks of key=values for every org – especially if they share the same settings. Also maybe an “inherited” type of org, where you can do multiple orgs in separate lines that share the same settings. I’ll leave that up to you.

Feel free to check out the code in Github.

The post Environment Variables in Custom Metadata Types appeared first on Michael Soriano.

A few Apex tips that I’ve picked up along the way

Michael Soriano — Sat, 14 Aug 2021 16:30:14 +0000

Salesforce’s server side language is called Apex. Apex is a strongly typed, object-oriented language that many say looks like Java. The language is strongly tied to the database and other objects in Salesforce, as well as its front end counterpart – Lightning.

As a side note, having written loosely typed languages all my life, Apex was a bit of a learning curve. I was a bit annoyed on how everything has to be type declared. Now I’m realizing the true power of static typing. Writing code is (almost) always bug-free 😎. Re-factoring is also so much easier and worry free.

Below are some tips and tricks that can be useful. I know Apex is not a popular language, but the concepts are pretty universal.

Parsing JSON strings

Almost guarantee, you will have to parse JSON for your applications. May it be from an API or accepting as parameters to your methods.

The simplest JSON response is something like below:

{
   key : val1,
   key2 : val2
}

You can do something like this:

Map parsedResponse = ( Map) JSON.deserializeUntyped(jsonstr);
System.debug(parsedResponse.get('key1')); //val1
System.debug(parsedResponse.get('key2')); //val2

The examples above simply gets the value part of the converted object. To the the “key” part, you have to loop through the object properties using .keyset() – almost similar to for..in in JavaScript.

For an array of objects like below:

[
{
   key : val1,
   key2 : val2
},
{
   key : val3,
   key2 : val4
}
]

It gets a little more involved:

List parsedResponse = (List) JSON.deserializeUntyped(response);
for (Object finalObj : parsedResponse) {
            Map tempObjMap = (Map) finalObj;
            System.debug(tempObjMap.get('key'))  //val1,val3 ;
            System.debug(tempObjMap.get('key2')) //val2,val4 ;
}

If the JSON string goes beyond many levels, you have to nest your loop corresponding to the levels – but inner logic should be the same. It can get complicated especially if its a mix of arrays and objects.

The key is using Apex’s JSON class. deserializeUntyped() converts the JSON string into a workable objects / list of objects.

Sending Bulk Email

So using the default sendEmail() from the Messaging class has some limitations. While its okay to send a few emails at a time, you can’t send them in bulk. I believe there’s a limit of 10 per execution. So doing sendEmail() in a loop of records – will stop at 10. (this limit can be inaccurate, but I know its pretty low).

Note that doing things in a loop such as sending emails, database commands is always a bad thing in Apex. There are many limits that you can hit – that you almost always have to do everything in bulk.

List emailAddressList; 
List emailSubjectList; 
List emailBodyList; 
List allEmails = new List();
for(Integer x = 0; x < total; x++){ //total, you convert to map of lists
    List toAddress = new List();// setToAddresses accept a List (array)
    toAddress.add(emailAddressList.get(x));
    String subject = emailSubjectList.get(x);
    String msgBody = emailBodyList.get(x);
    Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();
    mail.setToAddresses( toAddress ); // only takes a List (array) as noted above  
    mail.setSubject(subject);
    mail.setHtmlBody(msgBody);
    allEmails.add(mail);
}
List allMails = new List();
        
for( Integer j = 0; j < allEmails.size(); j++ ){
     allMails.add(theEmails.get(j));
}
Messaging.sendEmail( allMails );

So the key above is we’re sending allMails – which is a list of single email messages in bulk.

Select * Equivalent for querying Fields from Tables (Objects)

So this one is a little different. It’s more of a hack, because in Salesforce, a SELECT * is not allowed when doing SQL (actually called SOQL). This is for performance reasons I believe. It’s fair to think that programmers will lazily just keep using it instead of explicitly listing out the fields.

As a result, it becomes a bit tedious to maintain your select statements, when new fields are added to the table.

Set fields = MyObject.getSobjectType().getDescribe().fields.getMap().keySet();
String qry = 'SELECT '; 
Integer i = 1;
String sep = ', ';
for(String field : fields){
    sep = i == fields.size() ? ' ' : sep;
    qry += field +sep;
    i++;
}
qry += 'FROM MyObject';
Database.query(qry);

You can optionally query just the custom fields – by simply checking if field name ends with “__c”. You can use the nifty endsWithIgnoreCase() for that.

Debugging by Email

Logging to the developer console in the browser can be limited. Especially if you’re trying to view large datasets. The console will chop of the responses and add an elipsis “…” when they reach a specific size. Besides, running code locally, then going to the browser and looking at logs was never a good experience for me.

Sending yourself logs via email is still slow, but gets the job done. Long strings are shown in full, and you have full control of what you want to see.

public static void emailErrorLog(List errorLog){
        String body = '';
        for(string msg : errorLog){
            body += '\n\n' + ' -- ' + msg;
        }       
        Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();  
        mail.setToAddresses(new List{'youremail@example.com'});
        mail.setSubject('Error Log');
        mail.setPlainTextBody(body);
        Messaging.sendEmail(new Messaging.SingleEmailMessage[] { mail });        
}
//to use:
List debugLog = new List();
debugLog.add('some line -> ' + JSON.serialize(someObject));
emailErrorLog(debugLog);

Notice that we’re sending the message via setPlainTextBody() – just incase HTML gets inserted – and we don’t want that. Also, for objects, make sure you convert them all to strings by using JSON.serialize().

Get JSON from Static Resource

So sometimes you just want to get mock data from a flat file. Maybe you don’t want to store it in a table just yet. Or maybe you’re just quickly doing a prototype. This technique grabs the contents of a static resource through Apex, and optionally return it to the front end.

@AuraEnabled
    public static String getItems(){
        StaticResource sr = [SELECT Id, Name, SystemModStamp, Body FROM StaticResource  WHERE Name = 'mockdata' LIMIT 1];      
        return sr.Body.toString();
    }

Then from your JavaScript, you simply call your method via @import – and you use it as a Promise.

Note that above is assumes that your filename is mockdata.json.

SFDX Execute anonymous locally

Okay so this one isn’t really Apex, but SFDX – which is the command line interface for Salesforce development. Again, this is a result of the same downsides of working with the browser developer console. It takes too many clicks where you open the console, look for “Execute Anonymous” and a window pops up then “Execute”.

In VSCode, assuming you’re connected to your org, you can simply highlight the Apex code you want to run – and CTRL+Shift+P, and choose:

SFDX Execute Anonymous with Highlighted Text

This will run the code against your org, and show the results locally – in the Output tab.

The post A few Apex tips that I’ve picked up along the way appeared first on Michael Soriano.

Salesforce’s LWC (Lightning Web Components) – My First Thoughts

Michael Soriano — Mon, 28 Sep 2020 04:41:08 +0000

Oh no, another JavaScript framework to learn. At first, it sounds bad. But its a good thing actually. Because being stagnant in coding is bad. Always learning new things is the way to go.

Besides, newer frameworks (especially in JavaScript) show what older frameworks could’ve done better. This is the case with Lightning Web Components (LWC).

LWC is Salesforce’s newest iteration of Lightning called Aura. Actually, iteration is an understatement. It’s more like an overhaul. See, Aura is a pretty old framework – I would say at least a decade old. And its the way I learned how to code Salesforce apps. As newer JS frameworks come up, Salesforce decides to up their game.

Enter Lightning Web Components, LWC for short.

I started using LWC for a couple of small components, and I’m liking it a lot. LWC uses web standards and less boilerplate. Just JavaScript, CSS and HTML.

Import / Export

This is probably the biggest change. You can now write modules – just how JS intended it to be.

//importing modules into your component:
import { foo , bar } from "/path/to/lwc-component";
//exporting from your component
export { func1, func2}
//or you can export the entire file
export default class MyClass { ....

No more clunky adding components in the HTML so you can access the helpers. Or extending components, or including static resources – like how its done with Aura.

This is a big change and I’m really enjoying it.

Component Communication

I happen to like the two way data-binding that existed in Aura. But the new way of passing data between components is not that bad. After a few uses, it’s actually quite neat.

Parent to child is straightforward. Just like other frameworks – using “props” or component attributes.

//parent html:

//access it inside the child
export default class Child extends LightningElement {
   @api someData
...
// marking a property with @api makes it public - and writeable
// now each time parent changes someData - child changes as well

Keep in mind binding is now uni-directional (from Top to Bottom). When we need to pass data upwards, we pass events.

Oh, to fire a child component’s method from the parent, you can simply do something like :

this.template.querySelector("c-child").someEventInChild()

Make sure you make the method public by putting the “@api” on it.

Child to Parent is a little bit different than the example above. We still use attributes, but the attributes are actually custom events that fire.

//inside child JS
sendEmail () {
        const params = {somedata : "hello there..."};
        const evt = new CustomEvent("sendemail", {detail: params });
        this.dispatchEvent(evt);
    }
//note the custom event "sendemail"

The parent component will use the custom event that is dispatched from the child, but will only find it by prefixing an “on” with the event name:

//inside parent HTML:

Now you have access to the parameters sent (inside the “detail” property) of the parent function “sendSingleEmail“:

sendSingleEmail(event){
      console.log(JSON.stringify(event.detail) // here is our stuff..
}

Now, what about if the components are siblings? It would be cumbersome to use the techniques above just correct? And it doesn’t sound right if we have to reorder our components – just to avoid component sibling communication.

Sibling Components – use Lightning Message Service.

This is a component itself used for “publishing” and “subscribing” to data. This will solve our issue with sibling communication. I will not go through the process of how to use this service, you can read about that here:

Then in one component (where you want to receive data), you should be able to do something like below:

subscribe(this.messageContext, YourChannelName, (message) => {
    this.items = message.items;
});

That callback method in the end with the “message” parameter – can be used for all of your data manipulation in your current component.

Then in the other component, where the data is coming from, you do a “publish“.

publish(this.messageContext, YourChannelName, {items : this.items});

Pretty simple right? Of course there is quite a bit that I’m leaving out – but that’s up to you to dig up 😁

Overall, component communication is definitely harder than Aura. It does however remind me a little bit of Redux.

Apex Methods are JavaScript Promises

This one is Salesforce specific – but is still quite nice. Now you can use the “import” statement, for an aura enabled method in your Apex class. An aura enabled method is one that you can call from your front end component.

And if you’re sill lost – Apex is Salesforce’s server side language, while JavaScript Promises are well.. here’s an old article of what they are.

So you can do something like:

import getRecord from '@salesforce/apex/YourClass.getRecord';
//then you can use it like below:
let params = {recordid : id};
getRecord(params).then((result)=>{
    //process result...
}).catch((er)=>{
    //process error
})

The imported method from Apex becomes a JS promise – where you can handle it like regular JavaScript. You no longer have to muck with “$A.enqueueAction(action)” like before.

The only thing I don’t like is when you want to use multiple methods – you have to import them one at a time. I’m not sure if you can import all aura methods of a class. Maybe in future releases.

Templates

Not a Templating language like Liquid or Handlebars, just the template tag in HTML. Yes – LWC is composed of all template tags for logic in HTML.

I wouldn’t say it’s the most elegant code, but I’m getting used to it. Seeing something like:

It just feels a little weird. But this is not Salesfoce’s fault. This is web standards and that’s the way it has to be.

And that’s about it so far. Like I said, I am enjoying using LWC and learning it at the same time.

I do wish that Salesforce provide better docs. Most of the time I search for something – and it leads to a Github repo. And we’re just supposed to dig through the code to find an answer.

Its your turn.

Have you tried LWC? What do you think? Leave your comments below.

The post Salesforce’s LWC (Lightning Web Components) – My First Thoughts appeared first on Michael Soriano.

How to create simple Pagination using Lightning components and Apex

Michael Soriano — Wed, 17 Apr 2019 21:37:17 +0000

Let’s build something every web application needs in their results page: Pagination (aka Paging). This technique is necessary so we don’t bombard our users with all the items in our result page. Instead, we show them in “chunks” or “sets” of results. This is a very simplistic example – all we’re doing is a set of buttons that have page numbers on them. Once clicked, it will go ahead and fetch the results in that page.

A peak at what we’re building is shown below:

Disclaimer: I’m assuming you know how to work with Lightning components. I also hope you know JavaScript and HTML. There’s no downloadable code – you just simply have to follow along.

Currently, there are no built in lightning component for this type of functionality. Instead, we’re using lightning:radioGroup with type “button”. This will setup our page links nicely in a row, with clickable links and active/inactive states already added.

Ready to get started? Let’s begin.

Our Apex methods

First and foremost, let’s start with the backend. If you guys are familiar with SOQL – which is Salesforce’s version of SQL, you know that we have the 3 necessary keywords for our paging to become possible: ORDER BY, LIMIT and OFFSET.

ORDER BY – allows us to determine the order of our results. This makes it so that our result set will always follow a standard sort. This will make our paging deterministic and predictable.

LIMIT – allows us to limit the results in the page. So when we click a page – we will only show these number of records.

OFFSET – allows us to “skip” the records that we will not show. We’re “skipping” these records and start from the first record after our offset.

I’m building a method that I can call from my lightning component. Note the “@auraEnabled” keyword. The function then takes 2 arguments: ofst and lmt. What it returns is simply our queried object, with the results using SOQL.

@auraEnabled
public static List getNewHires(Integer ofst, Integer lmt){
	List onBoardingList = [SELECT
						Id,
						Name,
						FROM
						OnBoarding_Data__c
						ORDER BY Name DESC
						LIMIT :lmt
						OFFSET :ofst
						];
			return onBoardingList;
		}

Now we need another method to find out the total number of records there are in the database.

@auraEnabled
public static Integer getTotalItems(){
	Integer total = 0;
	String query = 'SELECT Id ';
	query += 'FROM OnBoarding_Data__c';
	List onBoardingList = Database.query(query);
	total = onBoardingList.size();
return total;
}

The above simply queries our same custom object, returning the total number of records.

My application uses a custom object for “on boarding” employees – so you will see OnBoarding references all through my sample code.

Our simplified Apex is ready. Let’s move to the front end.

The HTML

In our HTML, we’re setting up 4 attributes that we need for our pagination. You should be able to tell from their names what they’re for. We’re also setting the default values in them. Note the “pagesArray” attribute – is an array that will house the page objects that we need for our paging system.

The above is the output of our code. You see div wrappers that have Lighting Design System classes, along with aura directives to process our code. Such as our use of the aura:if – which checks the length of our pagesArray. Meaning – we’re only showing paging if there are pages to show.

You see our use of lightning:radioGroup. We also pass in “value” and “options” – which corresponds to our attributes we defined above.

We also have an onchange attribute calling our “doPaging” handler. We haven’t built this yet, but is coming up.

Let’s move on to our JavaScript.

The JavaScript

Let’s get down to business. We have our markup, we have our Apex waiting in the back end. All we need to do is tie them all up together. We do this with JavaScript – ideally in our helper file.

First, we create a “buildPaging” method. This method ideally fires on page load. But you can also call this method if you have some kind of filter mechanism.

buildPaging : function(component,event, helper){
		helper.callServer(component,'c.getTotalItems', function(response){
			var ttl = response;
			var lmt = component.get('v.limitPerPage');
			var pages = Math.ceil(parseInt(ttl) / parseInt(lmt));
			var pagesArray = [];
			for(var i=1; i<=pages; i++){
				var obj = {};
				obj['label'] = i.toString();
				obj['value'] = i.toString();
				pagesArray.push(obj);
			}
			component.set('v.pagesArray',pagesArray);
		},{});
	},

First thing you’ll see is our helper.callServer() method. This is basically our means of calling our Apex code above. To find out more about callServer() – see the post “Call Apex from Lightning“.

So from our total records, we can build our pagesArray. We call our getTotalItems from the backend, then we grab our “limitPerPage” attribute. We divide the total by the limit, and we’re doing a “ceil()” on it. This is so that we get a whole new page, even though there’s only 1 item in it.

Lastly, we’re building our pagesArray – but passing in the label and the value as an object.

Note the “toString()” method it. This is due to a bug with
lightning:radioGroup. It can only process strings. If you pass an integer – you would have to click it 2x to take effect! Whatever.

Let’s move on to our handler.

doPaging : function(component, event, helper){
		var lmt = component.get('v.limitPerPage');
		var val = event.getSource().get("v.value");
		var offset = parseInt((val-1) * lmt);
		component.set('v.curpage',val);
		component.set('v.offset',offset);
		helper.callServer(component,'c.getNewHires', function(response){
			if(response.length > 0){
			component.set("v.newhires", response);
				}else{
					console.log('no records');
				}
		},{'ofst' : ofst, 'lmt' : lmt});
	},

So first you see, lmt – which is static (set in our attribute). Then you see “val” – which is what was clicked. We get that number and multiply by the limit – so we get our offset.

We then call our Apex method with those parameters:

{'ofst' : ofst, 'lmt' : lmt}

Inside our callback, we simply set our response to the newly fetched data from our server.

Conclusion

And that’s about it. We’ve just built ourselves a very simplistic pagination using Lightning and Apex. There are many things we can do to enhance our code – like having a “previous” and “next” buttons – but I’ll leave that up to you.

Feel free to comment below.

The post How to create simple Pagination using Lightning components and Apex appeared first on Michael Soriano.

Repeating Inputs in Salesforce Lightning Components

Michael Soriano — Fri, 23 Nov 2018 01:40:14 +0000

What we’re building: An input field that can be duplicated (repeated) as part of a form. This is particularly useful when you want to capture information that you want to separate in different lines, and you don’t really want to use a textarea.

This way, we’re forcing our user’s to enter a value per input. In this scenario, we’re trying to grab a list a set of File Paths.

We’re using Lightning components, which is the framework Salesforce is using for their UI. A screenshot showing the pieces of what we want to accomplish is shown below.

See that we have inputs, a “More” link, and a “minus” sign – so we can remove the input directly.

Ready to build? Let’s begin.

Let’s start by defining an attribute in our .cmp file. Let’s call it “fileShares”, and its a “List” type. In Salesforce – a “List” is a an array in JavaScript. Here is how it looks

Our array will hold a set of Objects, which reflects each of the input that we’re building.

Now we’re ready to create our markup. We’re using lightning:input – which is nothing but an “input” in HTML. We give it several attributes, which is defined below:

aura:id with a value of fileShare.id
value – with a value of fileShare.value
label – with a value of fileShare.label
class – with a value of “fileShares” (nothing to do with our object, but simply for styling)

We also want to wrap it inside a DIV with a class of “fileSharesItem“.

Now let’s wrap it inside a aura:iteration tag, which is how you loop through items in Lightning.

Notice that we’re looping through v.fileShares – which is the aura:attibute we first defined. We prefixed it with a “v.”, because in Lightning – this means “value provider”. We also have two important attributes in our iterator: var and indexVar. Our variable “fileShare” declared in “var”, while “indexVar” holds the index – we’re calling “iVar” (the counter).

Let’s move on to our controller. This is the JavaScript file, that we first initialize the value of v.fileShares. Add the code below (ideally inside an initialize method during load).

component.set('v.fileShares', {'label': 'Enter Path', 'value': '','id': 'fileShare1'});

See that we’re using component.set() – and passing two parameters. The first is the property to set, then the value. In the case above, we’re setting up the ‘v.fileShares’ with an object. This means that we want just one field to show when the page loads.

Adding an Input

Let’s add the button that when clicked, a new input will be added to our form. Lighting supports data binding. This means that since we’ve binded our loop, all we worry about is the data. Remember our aura:iteration tag?

addMoreShareHandler : function(component, event, helper){
	var inputs = component.get("v.fileShares");
	var id = inputs.length+1;
	var obj = {
		'label': '',
		'value': '',
		'id': 'fileShare'+id}
		inputs.push(obj);
		component.set("v.fileShares", inputs);
},

Try it out and you should see our input repeated. Pretty neat right? How about removing the input? Let’s tackle that below.

The Remove Button

Let’s create an anchor tag – with a custom click handler. Also, let’s add a couple of attributes – so we know which one to remove. These attributes have to start with data- which is also known as “data-attributes“. I’ll explain more in our handler.





Now in our handler, we simply start with event.preventDefault() – which stops the link from behaving like a normal link. We don’t want the page to jump and refresh upon clicking.




Next, we grab the event, along with a property called currentTarget. What the currentTarget holds is information about what anchor tag was clicked.




So to access “data-idtoremove“, we do “dataset.idtoremove“



removeShareHandler : function(component, event, helper){
		event.preventDefault();
		var selectedItem = event.currentTarget;
                var idtoremove = selectedItem.dataset.idtoremove;
		var inputs = component.get("v.fileShares");
		for(var i=0;i




Then we loop through the inputs once again – by grabbing it from our component. We use .splice() to remove it from our array of objects.
Finally, let’s make the styles for our links.



The CSS:



For the remove link, we’re really trying to make it look like a “minus” button. We’re doing that with border-radius: 50%, along with a background color and a faint box-shadow. The rest of the CSS is mainly for positioning and sizing.



.THIS .slds-form-element.fileShares {
  margin-bottom:-5px;
}
.THIS .fileSharesItem {
  position:relative;
}
.THIS .removeShare {
  position: absolute;
  z-index: 999;
  right: -8px;
  top: 15px;
  border: 1px solid #ccc;
  width: 21px;
  line-height: 17px;
  padding: 0 0 2px 0;
  text-align: center;
  border-radius: 50%;
  font-size: 22px;
  background: #fff;
  box-shadow: 2px 2px 0 #e9e9e9;
}
.THIS .removeShare:hover,
.THIS .removeShare:active,
.THIS .removeShare:focus {
  text-decoration:none;
  background:#ebebeb;
}



Finally, we’re setting some hover styles by using :hover, :active and :focus also known as “pseudo selectors”. We simply want the cursor to change into a pointer, along with a subtle background change.
The final output:









So there it is. We just made a quick set of repeating inputs in Lightning. This also is a good crash course into Salesforce’s shiny new framework – which is gaining more popularity in the world of enterprise application development.




If you find this tutorial useful, or would like to see more – leave your comments below.
The post Repeating Inputs in Salesforce Lightning Components appeared first on Michael Soriano.



Let’s build a Map Application using Leaflet and Lightning Components
Michael Soriano — Sat, 15 Sep 2018 23:57:59 +0000

Salesforce’s Lightning component system is quite a robust framework where you can build full pledged single-page applications in a heartbeat. I especially like it’s built-in SLDS (styles), so all you have to really think about is the logic of your application. In this walk trough, we’re building a real life map application with Lightning. 



We’re using Google Places for our city lookup, as well as Leaflet for our map and finally Chatter for our chat component.




The goal is to have pins on the map – which is on the right side of our page. These pins are also shown in a list format on the left hand side of the page. Once a pin is clicked, the list on the left hand side is replaced by the pin details, along with the ability to chat about that specific pin directly below. When the “Close” button is clicked, the list re-appears, as well as the map zooms to its original view.




The same behavior is achieved when the pin on the map is clicked.









We also have a custom form, that allows us to add a pin right in the same page. The form has an auto suggest field for the cities.




Note that this is going to be a high level tutorial. You should be well versed in Lightning Components and JavaScript to follow along. A working knowledge of Salesforce is also needed.




Read to get started? Let’s begin.



Setting things Up



Before we can actually start coding, let’s back up and think about what we need. We will need a map software.  We need to store the locations in a custom object in Salesforce. And we need an Apex class to fetch these records for us. Seems simple enough? Let’s continue.




Static Resources




We’re using Leaflet – an open source map software which allows us to build a map on the page. All we need to do is pass it an array of locations (Longitude + Latitude) and Leaflet will populate magically. We also need LeafletMarkerCluster, an add-on to Leaflet, which allows us to bundle our pins together. This prevents the ugly grouping of many pins together.




So add these two zip files as static resources to Salesforce:



Leaflet
LeafletMarkerCluster








Custom Object




Each pin on the map is a record from a Custom Object in Salesforce. Let’s call ours “Pin”. Go ahead and build that custom object with the fields shown below.





You also might need to enter a few records. Since we’re dealing with coordinates, you will need to Google maps and grab this information. Don’t worry – this is just for the prototype. We are building our own custom form – that will take care of all this information for us.




The Apex Class




An Apex Class can behave sort of like a hash table that can hold our functions. This is how we’re going to interact with data from our Lightning components. Go ahead and create a class called “Pin”. Let’s add a method in there that grabs all of our Pins as well:



public with sharing class Pin {
    public static List getPins(){
        String sql = 'select Name, City__c, Lat__c, Long__c, Content__c, 
        Country__c, Region__c, Continent__c from Pin__c ORDER BY CreatedDate  
        DESC';
        List PinList = Database.query(sql);
        return PinList;
    }
}



Above is a class that has one static method “getPins“. This means that we don’t have to instantiate the class to use the method. The @auraEnabled declaration also make it callable directly from our Lightning components.




Component




Once that’s done, go ahead and create a Lightning component – let’s call ours “Pin“. Open pin.cmp and add the code below:





    
    
    
    




You will see that all we’re doing is setting our static resources up in our component file. We’re also doing controller=”Pin” in our component declaration. This means that we’re going to create an Apex class called “Pin”. We’ll get to that later.



Also note we have afterScriptsLoaded=”{!c.jsLoaded}” in our lightning scripts tag.  This is because we want the function jsLoaded to run as soon as our scripts are loaded. We don’t have this function yet – so loading the page will cause an error. We’ll get to this function soon.



Let’s continue building the markup.



Still in our .cmp file, after our scripts and styles – add our markup below :






        
            
            
        

        
            
        

 



The “aura:attribute” named “pins” is simply a holder for the pins we’re grabbing from the controller. 



More on this later.



The “aura:attribute” named “singlePin” is also a holder – for a pin that’s in focus. Again, more on this later.



This sets up our page. We’re splitting the page in two, one column is smaller (size_1-of-3) and the other bigger (size_2-of-3). We’re using built in Salesforce classes, with the prefix “slds”, stands for Salesforce Lightning Design System. In case you’re not familiar with it – it’s sort of like Bootstrap and React fused into a single framework.



The Map



So we’re ready to load the page and initialize our Leaflet map. We have our temp data in our custom object, we should have our component – along with the JavaScript files in place. Let’s write the jsLoaded() function (this is called when our scripts are done loading):



jsLoaded: function(component, event, helper) {
	var mapOptions = {
		zoomControl: true,
		zoomAnimation:false, //fixes the error when zooming in...
		markerZoomAnimation:true
	}
        var map = L.map('map', mapOptions)
        map.setView([48.85661400000001, 2.3522219], 2);
        map.scrollWheelZoom.disable();
        helper.map = map;
        L.tileLayer('https://server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer/tile/{z}/{y}/{x}', {attribution: 'Location'}).addTo(map);
        helper.callServer(component,'c.getPins', function(response){
        	component.set('v.pins',response);
        	helper.buildMap(component, event, helper, response);
        },{});
	}



Okay, a lot going on here. We’re setting some map default options (for more info on Leaflet, see their documentation).  We also have a very important helper function called “.callServer()“. This function is responsible for making the call to our Apex class, and returns our data. Note that I talk about callServer in a previous post. Simply add this function in your PinHelper.js file and that should be good to go.
Inside our callback we’re setting the v.pins in our .cmp file – which is an array of objects that came back from our server.



Right after we have a function called .buildMap() – which is a pretty big function and discussed in detail below.



The Map



So our pins our fetched from the server. I don’t know if you remember, that we are using a Leaflet add-on called LeafletMarkerCluster – which is what does the clustering of the pins – that are in the same proximity. What this does is – it creates a nice visual – the number of pins in a specific grouping, that you can click – and it will zoom in further to show the pins.



It also has a nice “spider” effect – for the clusters – which is really cool:




So what we need is a way to group our pins. Notice our custom object earlier – we have a field called “Region”. A region is similar to a “State” in the United States. So every pin that share the same region – will be clustered. Make sure your test data have pins that have the same region, and some that don’t.



Don’t worry – we don’t have to figure out what region our pins need to be – remember we’re building our own form.



The .buildMap() function



Now let’s dig in to the actual code that adds and groups the pins to the map. Open PinHelper.js and add the code below:



map : {},
mapLayers : {},
markerGroups : [],
markerList : [],
buildMap : function(component, event, helper, response){
        var map = helper.map;
        function onMarkerClick(e){
            //TODO: ADD LOGIC WHEN MARKER IS CLICKED
        }
        function onlyUnique(value, index, self) {
            return self.indexOf(value) === index;
        }
        function popupHtml(pinName){
            return '' + pinName + '';
        }
        var markerGroups = helper.markerGroups;
        for(var y=0; y




First, let’s set some variables in our helper (lines 1-4). These will act as a container as we pass them around from our controller to helper and vice versa.



Then the actual buildMap() function. We have gone through our pins and determined the unique regions and stuffed them into helper.markerGroups. Now starting in line 39, we loop through each of pin and add them to the map – according to their respective groups (region). Passing along the necessary options for each pin.



Your map should now load with the clusters and the pins.



The List of Pins (Left Side)



On the left side of the application – we show all of the pins – sorted by latest entry. Remember that we set our pins as a component attribute in our jsLoaded() function? Now all we need to do is loop through this in our component. But first, we have to check if there’s a singlePin – why you ask? This is to determine if we clicked on a marker on the map OR we clicked on any of the item in our list (which we’re still building).



We do this by using the aura:if directive.



The code below goes into the left hand section.




	
		Close
		 {!v.singlePin.Name}
		 
			{!v.singlePin.Region__c},  
			{!v.singlePin.Continent__c}
		 
		 
			 
		 
		 
		 
	
	
		Locations
		
		
			{!pin.Name}
			
				{!pin.Region__c} 
				{!pin.Country__c}
			
		
		
	




Let’s look at the singlePin scenario first – which is when an item is clicked. We are simply displaying some data from the singlePin – along with a button to close it (this .closeSinglePin() is not built yet). Then notice the use of  forceChatter:publisher and forceChatter:feed. These components are built in to Lightning – all we need to do is pass it a Id – and voila!



This will display our single pin nicely – along with a Chatter component right below it.









For the list, you see how we wrapped each pin as a lightning:button? That’s because we can click each item and something will happen. We have a c.markerClick handler on each item that we haven’t built yet.
The rest is simply markup of the pin details. Let’s create that handler.



markerClick : function(component, event, helper){
	var markerId = event.getSource().get("v.name");
	var marker = helper.markerList[markerId];
	var markerGroupId = marker['__parent']['_group']['_leaflet_id'];
	var parentChildCount = marker['__parent']['_childCount'];
	if(parentChildCount > 1){
		 for(var i=0; i




Remember, each item in our list – when clicked, will have the same behavior as clicking the pin (marker) on the map. So the above code is simply a trigger (using marker.fire()). But the check before that is to determine – if the marker is inside a cluster. If it is – we zoom to the layer first (using .zoomToShowLayer()), then fire.



Also, remember that we don’t have any behavior yet in when we click our pins (we have it as a TODO in our .buildMap() function above). Let’s go back and create that now.



function onMarkerClick(e){
	component.set('v.singlePin',{});  //resets to {}
	var id = e.target.options.alt;
	var latLong = e.target.getLatLng();
	if(e.target['_preSpiderfyLatlng']){
		latLong = e.target['_preSpiderfyLatlng']
	}
	map.setView(latLong);
	var pins = component.get('v.pins');
	for(var x=0; x




The handler above reset’s the singlePin to an empty object. Then we get the lat and long from the marker (we get it from “e” – or the event). We set the view on the map according to the coordinates.  Then finally – we loop through our pins – and set the v.singlePin into the one clicked.



Lastly, the .closeSinglePin() function:



closeSinglePin : function(component, event, helper){
        var map = helper.map;
        var defaultChatterFeed = component.find('defaultChatterFeed');
        var singlePin = component.find('singlePin');
        $A.util.removeClass(defaultChatterFeed, 'slds-hide');
        $A.util.addClass(singlePin, 'slds-hide');
        component.set('v.singlePin',{});
	map.setView([48.85661400000001, 2.3522219], 2);
        map.closePopup();
    },



The above simply hides our Single Pin and Chatter, resets the singlePin variable, then resets the map.



The Form



Finally, we come to the data entry section – where it will make it easy for us to add pins to our map. This form will have the necessary fields for our custom object – but most importantly, the auto-suggest field – that will auto populate the longitude, latitude, region etc.








I wrote a tutorial about this Auto-suggest field – using Google Places API, so I’m not going to get into that code. I’m simply going to go through the rest of the logic – that makes our form.



First off, we’re showing our form in a modal. Still in the same component, let’s add this to the lower section of our .cmp file:



Add New




	
		
			
			Add New Pin
		
		
			
				
				
				
					{!validationError}
				
				
				
				
				Content
				
				
				
					
						
							
							
								{!prediction.description}
							
							
						
					
				
				
				
				
				
			
		
		
			Submit
		
	







The lightning:button in the beginning, is what opens up the modal. It’s up to you how you want to show this button, and who to show it to.



The next three lines you’ll notice that we’re setting some new attributes. Again, these act as a containers for the variables we’re using in our component.



The SLDS dialog box contain a close button, a header, a footer  and a backdrop. The close button triggers a function closenewPin() when clicked. We’ll get to this later. Then we have a validation error list, then the form fields.



The “City” has an onchange handler called getCities() – which grabs the predictions from our Apex class. Again this was in a previous tutorial and find out how it’s done there.  The lightning:input fields that have a class “slds-hide” – are hidden fields. These fields are automatically filled – and will require no user interaction.



Finally, the lightning:button that takes care of saving the record.



Oh, we also have lightning:notificationsLibrary at the very end – which is Salesforce’s toast notification. We use this for messaging when successful.



Saving the Record



First let’s take care of the entering our record. Open the controller and add the method “saveRecord” below:



saveRecord : function(component, event, helper){
	var newPin = component.get('v.newPin');
	var str = JSON.stringify(newPin);
	//validation
	var errors = [];
	if(!newPin['Name']){
		errors.push('Name cannot be empty');
	}
	if(!newPin['City__c']){
		errors.push('City cannot be empty');
	}
	component.set('v.validationErrors', errors);
	if(errors.length > 0){
		return false;
	}
	helper.callServer(component,"c.savePin",function(data){
		helper.callServer(component,'c.getPins', function(response){
			component.set('v.Pins',response);
			component.set('v.newPin',{});
			helper.buildMap(component, event, helper, response);
			helper.closeModal(component, 'newPinModal');
			helper.showToast(component, 'success', 'A Pin has been added.');
		},{});
	},{"strsRecord" : str});
},



This function gets called as soon as the user clicks the “Save” button. First, we do some validation – and see if our required fields are filled in. If not, we set the validationErrors array up and exits.



Otherwise, we do a .callServer() twice. First to save the pin – and inside it’s callback, we do another .callServer() to get all of the pins. This is so that once we add a new pin – it grabs the new set of pins – so we can see it right away on the map. Remember I discussed about the .callServer() function in “Call Apex from Lightning components“.



This is the part that actually does the saving to the database. Add this to your Apex class – as another method:



@AuraEnabled
public static Pin__c savePin(String strsRecord){
	Pin__c strsRecord2 = (Pin__c)JSON.deserialize(strsRecord,Pin__c.class);
	try{
		if(strsRecord2 != null){
			insert strsRecord2;
		}
	}catch (Exception ex){
	}
	return strsRecord2;
}



Finally, we call .buildMap(), .closeModal() and .showToast(). You get what those functions are doing. Let’s add what’s missing in our helper. Open PinHelper.js and add the code below:



closeModal : function(component, modal){
	var cmpTarget = component.find(modal);
	var cmpBack = component.find('Modalbackdrop');
	$A.util.removeClass(cmpBack,'slds-backdrop--open');
	$A.util.removeClass(cmpTarget, 'slds-fade-in-open');
},
openModal : function(component,modal){
	var cmpTarget = component.find(modal);
	var cmpBack = component.find('Modalbackdrop');
	$A.util.addClass(cmpTarget, 'slds-fade-in-open');
	$A.util.addClass(cmpBack, 'slds-backdrop--open');
},
showToast : function(component, variant, msg){
	var toastSettings = {
		"title": variant,
		"message": msg,
		"variant" : variant,
		"mode" : "dismissable"
	}
	component.find('notifLib').showToast(toastSettings);
},



The helper functions above are pretty self-explanatory. For further explanation – especially about the utilities available in the $A object – refer to this question in StackOverflow.



closeNewPin : function(component, event, helper){
		helper.closeModal(component, 'newPinModal');
},
openNewPin : function(component, event, helper){
	helper.openModal(component, 'newPinModal');
},
closeSinglePin : function(component, event, helper){
	helper.closeSinglePin(component, event, helper)
},



Lastly, the above methods are in our helper, but we need to access them using our controller. Simply add the code below to our controller:



closeNewPin : function(component, event, helper){
		helper.closeModal(component, 'newPinModal');
},
openNewPin : function(component, event, helper){
	helper.openModal(component, 'newPinModal');
},
closeSinglePin : function(component, event, helper){
	helper.closeSinglePin(component, event, helper)
},



And after all is in place, our form should now be working:







Conclusion



There you have it. A cool map with events, clusters, a custom form – a good start of a real world application you can build inside Salesforce. Keep in mind these are mostly using Lightning – unless we had to build it ourselves. 



Next up should be filtering the results, adding a better Hover callout on the pins, maybe even having the latest chatter in the hover. The possibilities are endless.
The post Let’s build a Map Application using Leaflet and Lightning Components appeared first on Michael Soriano.



Build a Basic Page with Salesforce Data using Heroku Connect and NodeJS
Michael Soriano — Thu, 19 Jul 2018 17:58:44 +0000

This is a tutorial on how to fetch Salesforce Data from an external NodeJS application. To be more specific, we’re grabbing records in a SF custom object via Heroku Connect. Note that Heroku Connect utilizes an internal Postgres Database, to keep a “replica” of the data in Salesforce. Heroku Connect does a “poll” of this data – keeping both synchronized.



If you haven’t heard of Heroku, head on to their site to learn more. Heroku Connect is an add-on to Heroku, which is what makes this all possible. Heroku Postgres, also an add-on – and their implementation of PostgreSQL. And of course, Salesforce is a well known CRM software – which is where our data ultimately lives. NodeJS is JavaScript that runs on the server. 



We are using Node because it’s easy to work with – especially with Heroku.



The Business Case: Why would you need an “Interim” layer? Why go through Postgres first, then Salesforce? Because you certainly can do this. In our case, we have a limited license on the custom objects that we can use. So it makes sense to use Postgres for the majority of the application and use as little custom objects as possible. So designing the application in Postgres, and leave the final read / write in Salesforce makes sense.



Ready to get started? Let’s begin:



1) Create an app in Heroku



If you haven’t already done so, sign up for account with Heroku. You can get a free plan – which is enough to do this tutorial. Once signed up, go to the dashboard and create an app. In our case, we’re calling it “basic-api-app”.







This will spin up a new “dyno” and build the necessary elements to do a basic app. Check your project in the browser by clicking “Open app”. You should see something like below:




Now let’s continue to the next step – which is to build our project in locally.



2) Build Project Locally



For building locally, you will need the following items. These are pretty common industry tools, except Heroku CLI. Heroku CLI allows us to interact with our Heroku application using our local terminal.




Heroku CLI



Git



NodeJS



NPM




Let’s start from an empty directory and initialize Heroku Git. The commands below are listed in order, but is executed one at a time. I just listed them out for brevity.



heroku login
git init
heroku git:remote -a basic-api-app



The above logs you in Heroku, initializes Git in the current directory and adds the remote repo as our origin.  Note that your git repo will look like:



git.heroku.com/your-application.git



Now let’s grab the starter NodeJS pack from Heroku and add to our project.



git clone https://github.com/heroku/node-js-getting-started.git



This will create a folder called “node-js-getting-started” inside the current directory. You can simply copy the contents of that folder (except .git) paste it outside.








Now you can delete of the folder the starter pack came with.



Let’s go ahead and do our first commit. This adds the files to our remote repository.



git add .
git commit -m "first commit"
git push heroku master



Again the above commands are listed – but should be executed one at a time.



After the push – you should see that we have our NodeJS application running. Refresh the app url and you should see:







Let’s get this running locally. Let’s do the following commands:



npm install express ejs
node index.js



Open up your browser and browse to localhost:5000 – and you should see the same page that you saw above. Now we’re ready to move on.



3) Create a Custom Object in Salesforce



If you haven’t done so, sign up for a .org in Salesforce.com. This will allow you to utilize Salesforce and it’s many functionalities.



Now in your Salesforce org, let’s go to Setup > Quick find, type “Object Manager“. Click Object Manager from the search results and on the top right of the page, there is a “Create” button that will allow us to build the object we’re going to work with our application.








Now let’s create one that’s called “Example” (for lack of originality). This will create an object – with the basic fields.







I also added another field called “Description“. So our “Fields and Relationships” look like below:







Go back to “Quick Find” and look for “Tab“. This will bring us to the “Tabs” page.



Create a new custom object tab. This will allow us to add test data.







Now let’s add some test data. Get out of “Setup” and click on the new tab you just created. Add new test data and we should have something like below.







Now we’re ready for the next part, Heroku Connect.



4) Heroku Connect



In Heroku, in your app’s dashboard, look for the spot where it says “Add-ons“. Type in “Connect” and you should see “Heroku Connect” from the results.







Click the “Provision” once the modal pops up. You can simply choose the “Hobby Dev-Free” plan for now.








After success, you should see this in your Heroku dashboard:








You also need the Heroku Postgres  add on. Do the same steps above, but for Heroku Postgres. When everything is in place, now we can continue to setup a connection. Click on “Setup Connection“:







The next page simply verifies the database to use, and the schema name for your connection. Simply click “Next“.








The next screen initializes the authorization part. Heroku will attempt to connect to your Salesforce. Select “Sandbox” and follow the prompts.







When you get to the login – add your credentials.







Once this process is complete – we should be good to go. Now we can do the real work.
Let’s create our first “Mapping“. From the list of Salesforce objects – choose “Example__c” – the custom object:







Besides the basic fields – let’s make sure we have the two fields that we need: Name and Description__c. At the moment, we’ll just focus on “Salesforce -> Database” part. Let’s get to the bi-directional style at a later time.








If all goes well, we should see the screen below. This shows that we’re all “Synced“.



This means that the columns in our custom object, has been successfully “mapped” to our Postgres table. It also shows that the records in Salesforce has been copied over.







To prove this, click on the “Explorer” tab, and you should see our dummy records that we’ve entered a while ago.







This brings us to the final step. Which is writing the code that pulls this data from Heroku.



5) Access the data via NodeJS



First, let’s grab the “DATABASE_URL” from our application. You can find this under your app’s Settings > “Config Vars” section. Copy this value. 



Go back to your local setup. Open the folder in your favorite text editor. Once that’s up, create a “.env” file. Quick note: a .env file is a configuration file that stays in your local setup. It is not committed to Git, and is only honored when your localhost is running (using the command: heroku local).



Open this file and add the key “DATABASE_URL” , with the value that you copied previously from your heroku app. 



With this in place, we can continue to work with our application – with the Postgres database we provisioned in Heroku. 



Let’s add a custom route in Express. Open “index.js” and add the code below:



const { Client } = require('pg');
express.get('/db', (req, res) => {
  //rest of the code here...
})



This simply sets up a page we can access via the “/db” route. We’re also requiring the module “pg” – which we need to install via npm:



npm install pg



Now that our pg module is installed, let’s add some code inside our route handler:



var dbOpts = {
      connectionString: process.env.DATABASE_URL,
      ssl : true
    }
const client = new Client(dbOpts);
client.connect();
client.query('SELECT id, name, Description__c FROM salesforce.example__c;', (err, dbRes) => {
      if (err) throw err;
      res.render('pages/db',{
        results : dbRes.rows
      });
      client.end();
    });
client.end();



The code above sets up the options for our Postgres client. We connect, then run a simple “SELECT” statement. Inside the query function, we pass the result – as an object to the “db.ejs” temlplate that we have. Finally, we close the connection.



Note that for other database interactions such as INSERT, UPDATE, DELETE – consult with the pg module documentation.



Open db.ejs inside the pages folder and modify the code that is inside the DIV.container:




    <% results.forEach(function(r) { %>
        
            <%= r.name %>
            <%= r.description__c %>
        
    <% }); %>




The above is a simple markup that loops through each of the items in our table and spits it out.
Finally, let’s run our code. Open a terminal and run:



heroku local



This loads the local .env file and starts up our application on the specified port. Open up a browser and navigate to localhost:5000/db – and you should see our page with the data:







Finally, let’s push the code to Heroku:



git add .
git commit -m "added more files"
git push heroku master



Conclusion



So there you go – we have a basic page that can interact with Salesforce data via Heroku. As you can see, Heroku Connect does the hard work of building a Postgres database and mapping it with Salesforce.  



Once this is setup – all you need to worry about is your application and the Postgres database. The rest is done by Heroku.
The post Build a Basic Page with Salesforce Data using Heroku Connect and NodeJS appeared first on Michael Soriano.



Let’s Build an AutoSuggest Lightning Component with Google Places API
Michael Soriano — Fri, 11 May 2018 22:18:19 +0000

I had the challenge of building an input form that brings up a list of cities as you type. One that has the coordinates of each city – because I’ll need to enter that into a map. An “auto-suggest” or “auto-complete” city input – inside a custom form inside Salesforce. It turns out, that it wasn’t so bad.



We’re using Google Places for our API and Lightning Components for our Front End. If you’re not familiar with Lightning, check their documentation.



Our component will look like below.







Ready to start coding? Let’s start.



API Setup



Let’s get Google going. Remember, each time a user type a character – it will ping Google for suggestions. Also, the suggestions does not contain coordinates for each item, so we will need to ping the API as soon as the user selects a place.



I’m going to assume that you know how to get an API key from your Google account. If not, here is their API documentation.



The first part is getting the suggestions. Below is the URL that we need for that:



https://maps.googleapis.com/maps/api/place/autocomplete/json?input=TERM&key=YOURKEY



Looking at the above, we’re passing in what the user is typing where it says “TERM”.
The second part is when the user selects an item:



https://maps.googleapis.com/maps/api/place/details/json?placeid=PLACEID&key=YOURKEY



The above shows a “placeid” parameter that we get from each suggestion. So when the user clicks – we pass the id to the above URL.



Now that we have our Places API setup. Let’s move forward to our Salesforce code.



Build the Apex Class



One thing to note is that our Lighting components cannot reach out to Places API directly. Google doesn’t allow CORS to their endpoints – so we simply cannot do this. Nor would we want to – because if we do this via JavaScript – we will be exposing our keys. So we need the server to do the calls. In Salesforce, we use Apex.



We also have to add “maps.googleapis.com” to the remote site settings in Salesforce. To do this, go to “Setup” > “Security” > “Remote Site Settings”.



Click on “New Remote Site” and add the required fields:







Now, let’s create our Apex Class. Copy the code below and add it to your Class:



@AuraEnabled
	public static string getSuggestions(String input) {
	    String url = 'https://maps.googleapis.com/maps/api/place/autocomplete/json?'
	            + 'input=' + EncodingUtil.urlEncode(input, 'UTF-8')
	            + '&types=(cities)' + getKey();
	    String response = getResponse(url);
	    return response;
	}
@AuraEnabled
	public static string getPlaceDetails(String placeId) {
     	String url = 'https://maps.googleapis.com/maps/api/place/details/json?'
	            + 'placeid=' + EncodingUtil.urlEncode(placeId, 'UTF-8')
	            + getKey();
	    String response = getResponse(url);
	    return response;
	}
	public static string getResponse(string strURL){
		Http h = new Http();
		HttpRequest req = new HttpRequest();
		HttpResponse res = new HttpResponse();
		req.setMethod('GET');
		req.setEndpoint(strURL);
		req.setTimeout(120000);
		res = h.send(req);
		String responseBody = res.getBody();
		return responseBody;
	}
	public static string getKey(){
		string key = 'xxxxxxxxxxxxx';
		string output = '&key=' + key;
		return output;
	}



Note the two methods that have @AuraEnabled: getSuggestions() and getPlaceDetails(). These are the two endpoints we will be calling from our JavaScript in our Lightning component. Both methods are quite explanatory, they simply accept parameters from our front end, go out to Google and return the results.



Don’t forget to add your API key to the method getKey().



Let’s move on.



Our Component



The component (.cmp file) will need a few things. First, we need a couple of attributes to hold our values. One for location and one called “predictions”. The location is the value that will be in our input, while the predictions is what will show directly beneath it – in an unordered list. Note that this is what comes back from our API.  So add that first to your component.








We’re using “lightning:input” for our form field. We add a label, name, an aura:id, a value and an onchange attribute. The label and name is pretty straightforward, the aura:id – is simply a way for us to reference it in our controller.



The value – binds the input to our attribute “location”. Which we show as “v.location“.



The onchange – we’re attaching to a function in our controller named getCities(), which we refer to as “c.getCities“.







We’re using an unordered list for our suggestions. So we use the code below:




 	
		
			
				{!prediction.description}
			
		
	




Notice we wrap it an “aura:if”  – which determines if our predictions object has more than zero length. Remember, predictions is coming straight from the API.



Then we have an “aura:iteration” for each prediction to show up in a list item > anchor tag. Each anchor tag has an “onclick” (which we’re attaching to getCityDetails()) and a “data-placeid” (I’ll explain later).



The Controller



So remember in our component we have 2 methods: getCities() and getCityDetails()? Those both go in our controller.



Our getCities() method is called every time we change the input field. Meaning – every time we type a letter, it calls this method.



First it sets up an object called “params“, which has one item in it called “input“. This is what we’re sending our Apex class through the use of helper.callServer(). This helper is explained in my previous post “Call Apex from Lightning“. Once our Apex responds with some suggestions – we parse it through JSON.parse() and set it to our component attribute called “predictions”.



getCities : function(component, event, helper){
	var params = {
	  "input" : component.get('v.location')
	}
	helper.callServer(component,"c.getSuggestions",function(response){
		var resp = JSON.parse(response);
		console.log(resp.predictions);
		component.set('v.predictions',resp.predictions);
	},params);
}



So our UL of suggestions will only populate if there’s a response from the server.



Finally, getCityDetails() get’s triggered when we choose an item from our UL (or click the anchor tag).
Remember the “data-placeid” attribute that we have for each anchor tag? This is where we will need it.



We grab the value of “data-placeid” (which is the Place Id required for our API) through the event.currentTarget. We then create the “params” object like we did above.



getCityDetails : function(component, event, helper){
	var selectedItem = event.currentTarget;
        var placeid = selectedItem.dataset.placeid;
	var params = {
	   "placeId" : placeid
	}
	helper.callServer(component,"c.getPlaceDetails",function(response){
		var placeDetails = JSON.parse(response);
		component.set('v.location',placeDetails.result.name);
		component.set('v.predictions',[]);
	},params);
}



We then do a helper.callServer() and when finished, we parse then set the v.location (the input value) and v.predictions back to empty.



I specifically needed the coordinates for the selected location, which can easily be grabbed from the response. You can do something similar.



The Final Product:



Below is a short screengrab of the final output. The lightning:input makes our field look better than just a regular input. Also, this is a “barebones” solution for an auto suggest field. You can greatly enhance by adding icons, additional description for each place, maybe some more events (like on tab, enter etc).





The post Let’s Build an AutoSuggest Lightning Component with Google Places API appeared first on Michael Soriano.



Call Apex from Lightning components
Michael Soriano — Mon, 07 May 2018 17:20:45 +0000

I’ve decided to do some write up on Salesforce – especially Lightning development. Lightning is basically Salesforce’s proprietary JavaScript and CSS Framework bundled into one. It’s a component-based system, mobile friendly, with the power of a server side language (Apex), just in case you need it.







In the following tutorials, you might see a “helper.callServer()” method – which I’m outlining below:



callServer : function(component,method,callback,params) {
        var action = component.get(method);
        if (params) {
            action.setParams(params);
        }
        action.setCallback(this,function(response) {
            var state = response.getState();
            if (state === "SUCCESS") {
                // pass returned value to callback function
                callback.call(this,response.getReturnValue());
            } else if (state === "ERROR") {
                // generic error handler
                var errors = response.getError();
                if (errors) {
                    console.log("Errors", errors);
                    if (errors[0] && errors[0].message) {
                        throw new Error("Error" + errors[0].message);
                    }
                } else {
                    throw new Error("Unknown Error");
                }
            }
        });
        $A.enqueueAction(action);
    }



If you’re ever going to do some kind of call to an Apex class – this is a must have in your helper. Think of it as sort of like jQuery’s $.ajax() method – but limited to a specific class.



Salesforce has the same exact code in this doc with some explanation, but I wanted to write it up in my own words. Let’s break it down below.



As mentioned, this is what we need to call an Apex class from our components. It is basically a wrapper to an XMLHttpRequest, along with other utilities to make our JavaScript easier.



Again, components are front end code – Apex sits in the server. This method is the communication between the two.



Set up Apex



First, you declare a class. This is done in our .cmp (component) file, way at the top – it looks like below:







Now we’re set up with an Apex class called “MyClass”. Let’s build that class, with a method called “doSomething()”:



public with sharing class MyClass{
   @auraEnabled
   public static string doSomething(String input) {
      return input
   }
}



Note the “@auraEnabled” declaration. This allows us to access it from our JavaScript.



With the our helper in place, all we need to do in our controller will be something like below:



helper.callServer(component,"c.doSomething",function(response){
    //INSIDE OUR CALLBACK
    console.log(response) //RESPONSE FROM OUR APEX METHOD
},{})



You see, our helper had arguments that looked like below:



callServer : function(component,method,callback,params) {…



Which is what we’re doing in our controller. The second parameter “c.doSomething” – is the method in our Apex class. The 3rd parameter “callback” – is an anonymous function that get’s triggered through “.apply()” in our helper. This is executed when our Ajax call finishes. And we’ll have access to the response.



Sending Parameters



You can send information to your Apex class by setting an object to the last parameter called “params”. In our example above, we’re simply passing an empty object “{}”. But in reality, you will most likely send something to the server.



Our method “doSomething” is expecting a string called “input”.



The object we can pass will look like below:



{
  "input" : "somevalue"
}



Notice the key “input” must match our server variable “input”.



If you would like to pass another value, simply add another key:



{
  "input" : "somevalue",
  "input2" : "somevalue2"
}



In our doSomething method:



doSomething(String input, String input2)



You can also pass multiple values as a JSON string, so in your controller:



var str = JSON.stringify({"input1":"somevalue","input2":"somevalue2"});
var params = {"strsRecord" : str};
helper.callServer(component,"c.doSomething",function(){}, params);



In your Apex class:



doSomething(strsRecord){
   List st = JSON.deserialize(strsRecord);
   System.debug('Here is the params:' +st);



“Promise” Style



In JavaScript, a promise is “an object that may produce a single value some time in the future“. So our helper above is a perfect example of this. Let’s rewrite it using a promise, so we can use it more efficiently, and elegantly.



By this, I mean avoiding “callback” hell. See, callbacks are okay if we’re dealing with a single call. But if we were to make multiple nested calls (especially one that needs relies on the first response etc), it gets ugly real fast like below: 



Callback hell:



helper.callServer(component,"c.doSomething1",function(response1){
     helper.callServer(component,"c.doSomething2",function(response2){
         helper.callServer(component,"c.doSomething3",function(response3){
               //THIS GETS UGLY...
          },{})
     },{})
},{})



So let’s convert it to use a JavaScript promise instead: 



callServer : function(component,method,params) {     //PROMISE BASED
        var promiseObj = new Promise(
            function(resolve, reject){
                var action = component.get(method);
                if (params) {
                    action.setParams(params);
                }
                action.setCallback(this,function(response) {
                    var state = response.getState();
                    if (state === "SUCCESS") {
                        var data = response.getReturnValue();
                        resolve(data)
                    } else if (state === "ERROR") {
                        var errors = response.getError();
                        console.log(errors);
                        reject(errors);
                    }
                });
                $A.enqueueAction(action);
            }
        );
        return promiseObj;
    }



As you can see above, there are no more callbacks being passed. All we need are the 3 parameters: “component”, “method” and “params”. 



Now we can use this like below:



helper.callServer(component,"c.doSomething",{}).then(function(response){
   console.log(response)
})



You see the use of “.then()”. We’re no longer restricted to a single callback function we were previously. We can even use multiple .then() methods all over our code:



var ajax = helper.callServer(component,"c.doSomething",{});
//first .then()
ajax.then(function(response){
   console.log('do something here');
})
//second.then()
ajax.then(function(response){
   console.log('do more stuff here');
})



We can also chain Promise methods like so: 



var ajax = helper.callServer(component,"c.doSomething",{});
ajax.then(function(response){
   console.log(response);
}).catch(function(error){
   console.log(error)
}).finally(function(){
   console.log('this always runs')
})



As you can see, the “Promise” style of the helper can help you write more efficient code. 



So keep this in your Lightning helper, in order to communicate with Apex. Its almost always guaranteed to be used at least once in your Salesforce applications. 
The post Call Apex from Lightning components appeared first on Michael Soriano.

Salesforce Archives - Michael Soriano

Simple CICD for Salesforce using SFDX and GitHub Actions

The Struggle

Modular Repos, 2 Branches

GitHub Actions is the glue

Features

How to Use

Environment Variables in Custom Metadata Types

Why not use Custom Settings?

Why not YAML or JSON?

Setup the Custom Metadata Type

Parsing the Variables with Apex

The getEnvVars() method

The getEnvVar() method

Improvements

A few Apex tips that I’ve picked up along the way

Parsing JSON strings

Sending Bulk Email

Select * Equivalent for querying Fields from Tables (Objects)

Debugging by Email

Get JSON from Static Resource

SFDX Execute anonymous locally

Salesforce’s LWC (Lightning Web Components) – My First Thoughts

Import / Export

Component Communication

Apex Methods are JavaScript Promises

Templates

There's an error

How to create simple Pagination using Lightning components and Apex

Our Apex methods

The HTML

The JavaScript

Conclusion

Repeating Inputs in Salesforce Lightning Components

Adding an Input

The Remove Button

The CSS:

Let’s build a Map Application using Leaflet and Lightning Components

Setting things Up

The Map

The Map

The List of Pins (Left Side)

{!v.singlePin.Name}

Locations

The Form

Conclusion

Build a Basic Page with Salesforce Data using Heroku Connect and NodeJS

1) Create an app in Heroku

2) Build Project Locally

3) Create a Custom Object in Salesforce

4) Heroku Connect

5) Access the data via NodeJS

Conclusion

Let’s Build an AutoSuggest Lightning Component with Google Places API

API Setup

Build the Apex Class

Our Component

The Controller

The Final Product:

Call Apex from Lightning components

Set up Apex

Sending Parameters

“Promise” Style