Thursday, November 14, 2019

Pre-populate Field Values on Standard Pages in Lightning

In Salesforce classic, we used to specify the field values in URL parameters (URL hacks) to pre-populate the field values in standard page layouts.

In lightning, URL hack don't work. So if we have to open standard page in lightning with pre-populated field values, then we can use "e.force:createRecord" event to open new record page with default field values.

In this blog, I will be creating a lightning component which will be added to account page layout. This component will display button "Create Quick Contact" to create new contact. When user will click on this button, standard new contact page will open with default field values.

Below is complete code:

Now you add this component on account page layout.

Now when you click on Create Quick Contact, standard page will open for new contact creation with pre-filled field values specified in controller.js.


Here you can see recordtypeId, phone, email and account are pre-populated.

Hope this will help!!




Thursday, November 7, 2019

How to Convert Salesforce Attachments into Salesforce Files

As now everyone is migrating to Lightning, Salesforce supports files instead of attachment. So while migrating to lightning, we have to convert all attachments to files. Salesforce provide an appexchange app called magic mover for this purpose.

If you don't want to install this app and would like to convert attachments to files, then you can do it with very simple apex script.

I have created a batch class which will convert all attachments related to object (based on query that you pass) to files and you will receive an email with all details once batch job is completed.

Suppose you have to convert all attachments of Contact to files, then use below script:
SK_ConvertAttachmentsToFilesBatch newjob= new SK_ConvertAttachmentsToFilesBatch('select id from Contact');
database.executeBatch(newjob, 1);



I will suggest to run this batch job with minimum batch size (recommended size is 1). Suppose if you run this script with more batch size and one parent record have multiple attachments and attachment size is large, then you may face heap size error in apex script. So it is advisable to run this script with batch size as 1.

Hope this will help!!

Saturday, November 2, 2019

Migrate Attachments from one Salesforce to another Salesforce Org

Through this blog, I will be sharing simple apex code through which you can fetch the attachment from another org and save it in your current org as attachments. This process includes 2 API calls as mentioned below:
  • First API call to fetch attachment details like attachment name etc.
  • Second API call to fetch attachment body.  Attachment body will be returned in binary format so get the response body as blob and then use it to insert attachment in your current org.

Below is code snippet which you can use to migrate attachment:


In order to test above script, run below mentioned script in developer console:

string sourceOrgUrlAttachmentId='00P0K00001ZvWpe';
string sourceOrgURL='https://sk02-dev-ed.my.salesforce.com';
string access_Token='0XXXXXXXXXXXXXXXXXX8ADac';
string currOrgParentRecid='00190000004Awot';
string result=SK_AttachmentMigrationHelper.findAttachmentDetails(sourceOrgUrlAttachmentId,sourceOrgURL,access_Token,currOrgParentRecid);
system.debug('***attachment Id after migration:'+result);

Instead of access_token, you can also use sessiond of user from source Org.

Refer below URL to understand how to get access token from salesforce:

ACCESS TOKEN USING OAUTH 2.0 IN SALESFORCE


How to get all attachments related to parent record Id

Specify endpoint URL as mentioned below while performing callout:

string parentRecId='001xxxxxxxxxxx';
EndPointURL= EndPointURL +'/services/data/v45.0/query/?q=select+id,parentid,ContentType,+name+from+attachment+where+parentid=\''+parentRecId+'\'';


How to migrate bulk attachments from one salesforce org to another

Before migrating the attachments, you will be migrating the parent records from source org to target org. So while migrating store the source org record Id in new custom field in target org.

Now write a batch class in target org and take references from above code to process records one by one. Execute the batch class with 1 batch size.

Hope this will help!!

Tuesday, September 24, 2019

Custom Label : Fetch all Custom Label Information through Execute Anonymous Script

CustomLabel is available in Tooling API and can be used to get all CustomLabel Information. With single callout, REST API return 2000 records and then provide "nextRecordsUrl" attribute which contain URI for next set of custom label.

If you want to create class in your org and execute it methods to get custom label information, then refer below URL:

Custom Label : Fetch all Custom Label Information using Tooling API

But if you don't want to deploy new class to production or any org to get custom label information, then you can run below apex script in execute anonymous window in developer console to get custom label information.

Hope this will help!!!

Monday, September 23, 2019

Box API : How to Regenerate Access Token from Refresh Token

Box and Salesforce can be integrated to store files on box and link them with salesforce records. You can also write apex script to extract files or attachments from Salesforce and upload it into box folder.

For basic understanding on how to generate access token from box, refer below URL:
Box and Salesforce Integration

Whenever we perform handshake with box using OAuth, box returns access token along with refresh token. Below is sample JSON response for access token:

{
"access_token": "h91xxxxxxxxxxxxxxxxxxxx8",
"expires_in": 4012,
"restricted_to": [],
"refresh_token": "bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxM",
"token_type": "bearer"
}

here expires_in specifies the duration for which this access token is valid. After this duration, user will recieve 401 error so we need to regenerate the access token using refresh token.

Below is apex code which can be used to regenerate new access token and refresh token. In order to regenerate you need clientid, client secret and refresh token.

Above mentioned code is self explainatory.


Hope this help!!!


Tuesday, September 3, 2019

Custom Label : Fetch all Custom Label Information using Tooling API

Considering the organization which have huge metdadata, its very difficult to fetch custom label information using Metadata API. When I tried using Metadata API in org which has more than 15000 custom label, then I was getting "IO Exception: Exceeded max size limit of 6000000" error.

CustomLabel is available in Tooling API and can be used to get all CustomLabel Information. With single callout, REST API return 2000 records and then provide "nextRecordsUrl" attribute which contain URI for next set of custom label.

I have created below code snippet which can be used to fetch all custom labels in csv file. User will receive email with attachment which contains Custom Label Id, Name and Value.

After saving this apex class, run below script in developer console and you will receive email with csv file with all custom label information.

SK_CustomlabelUtility.fetchAllCustomLabels();

Below is snapshot of csv file:



This utility can be helpful to take backup of custom labels in sandbox or production or find dependency or reference of any metadata component like fields in custom label.

Hope this will help!!

Looking forward for everyone comments and feedback.

Friday, August 23, 2019

Development Lifecycle and Deployment Designer : Exam Preparation Guide and Tips

First of all big thanks to everyone who follow my blogs and provide their valuable feedback. This motivates me to write something every month and share my knowledge by taking out time from so called busy professional life.

This is my 150th blog and have reached 500K pageviews with (500+ daily page views). Once again thanks to everyone!!

Along with this, I am really excited to get "System Architect" credential after completing "Development Lifecycle and Deployment Designer" Exam.



If you want to prepare about other exam for "System Architect" then refer below URL:
Through this blog, I will be sharing some information which will help you to prepare for this exam.

As always, I started with trailmix Architect Journey: Development Lifecycle and Deployment designed for this exam. It has lot of information about different aspect for this exam.

Now I will specify different topics which will help you:

Migration Tools
  • You should know the use case on when to use Change Sets, Force.com migration tool (ANT), force.com IDE.
  • When you have separate release team for deployments, then being architect you need to make sure that all necessary components for deployment are specified in package.xml and associated metadata in .zip file to release management team.
  • There are few exception which can not be migrated using Metadata API. So we have to deploy these components manually. Refer Unsupported Metadata List for deployments
  • Custom setting can be migrated but custom setting data needs to be migrated manually after custom setting deployment.
  • Prefer custom metadata types over custom settings if you want to migrated data during deployments.
  • If you want to remove/delete certain metadata for clean up purpose, then create destructiveChanges.xml file and specify all components in that and then deploy using force.com migration tool. 

Sandbox Strategy

Salesforce offers sandboxes and a set of deployment tools, so you can:
  • Isolate customization and development work from your production environment until you’re ready to deploy changes.
  • Test changes against copies of your production data and users.
  • Provide a training environment.
  • Coordinate individual changes into one deployment to production.

Sandbox Types
  • Developer Sandbox
A Developer sandbox is intended for development and testing in an isolated environment. Developer Sandbox includes a copy of your production org’s configuration (metadata).
  • Developer Pro Sandbox
A Developer Pro sandbox is intended for development and testing in an isolated environment and can host larger data sets than a Developer sandbox. A Developer Pro sandbox includes a copy of your production org’s configuration (metadata). Use a Developer Pro sandbox to handle more development and quality assurance tasks and for integration testing or user training.
  • Partial Copy Sandbox
A Partial Copy sandbox is intended to be used as a testing environment. This environment includes a copy of your production org’s configuration (metadata) and a sample of your production org’s data as defined by a sandbox template. Use a Partial Copy sandbox for quality assurance tasks such as user acceptance testing, integration testing, and training.
  • Full Sandbox
A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and staging. Full sandboxes are a replica of your production org, including all data, such as object records and attachments, and metadata. The length of the refresh interval makes it difficult to use Full sandboxes for development.

When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.
  • The default is to omit field tracking, but you can include up to 180 days of field tracking. If you track field history for many objects in your production org, specify fewer days to avoid generating an excessive amount of data.
  • Chatter activity data can be extensive, which can add a significant amount of time to your Full sandbox copy.
Limit the amount of field history that you copy, and copy your Chatter data only if you need it for your testing use cases.

Sandbox Refresh Interval




  • As a best practice, development and testing should not happen in same sandbox.
  • If testing and development is happening in same org, then tester may face issues as development is going in same org.
  •  Salesforce releases happen first in sandbox and then in production environment. So to identify if salesforce release will not impact your current development or features, test the functionality in preview sandbox (sandbox which is already upgraded to new release before production). 
  • Salesforce sent notification about all instance or domain which are part of preview sandbox before every release. If your sandbox is not part of that, then raise request with salesforce to include your sandbox.

Continuous Integration

Continuous integration (CI) is a software development practice in which developers regularly integrate their code changes into a source code repository. To ensure that the new code does not introduce bugs, automated builds and tests run before or after developers check in their changes.

Using continuous integration, a product is built to include and integrate every code change on every commit (continuously), by any and all developers. An automated build then verifies each check-in, letting teams detect problems early.

Continuous integration (CI) is a component of the continuous delivery process that enables developers to integrate their updates into the master branch on a regular basis. With CI, automated tests run before and after each change is merged, validating that no bugs have been introduced.
  • When you have multiple concurrent projects running along with new features, then always utilize the source control, build tool for deployment and automated test script.
  • Continuous Integration Tools  includes Source Control Tool, Force.com Migration tool and sandbox environment where build can be validated and run automated test.
  • Utilize unit and automated functional test script as part of continuous integration strategy.
  • When multiple developers are working on different functionality along with bug fixes, then create separate branches for developers and merge their changes in common branch for testing.

Continuous Delivery

Continuous delivery ensures that code can be rapidly and safely deployed to production by manually pushing every change to a production-like environment. Since every change is automatically delivered to a staging environment, you can deploy the application to production with a push of a button when the time is right.

The additional step of pushing the code to a staging environment is what makes continuous integration different than continuous delivery. Having a green (successful) build with CI doesn't mean your code is production ready until you push it to a staging environment that matches the final production environment.


Continuous Deployment

Continuous deployment is the next step of continuous delivery. Using Continuous Deployment, every change that passes the automated tests is deployed to production automatically while continuous delivery is manual step.Most companies that aren’t bound by regulatory or other constraints should have a goal of continuous deployment.

While not every company can implement continuous deployment, most companies can implement continuous delivery. Continuous delivery gives you the confidence that your changes are serving value to your customers when you release your product, and that you can actually push that button anytime the business is ready for it.



Understanding Packages

A package is a container for something as small as an individual component or as large as a set of related apps. After creating a package, you can distribute it to other Salesforce users and organizations, including those outside your company.
  • Understand the difference between manage and un-manage package.
  • Manage package can be created in Developer edition and Partner Developer Edition.
  • Aloha app is status given to manage package so that it won't count against limits imposed by SFDC. This is mainly utilized for Group and Professional editions.
  • Unlock Packages 
    • Unlocked packages help you add, edit, and remove metadata in your org in a trackable way so you can reuse components and upgrade your Salesforce apps easier and faster. They encapsulate all the metadata changes and updates you plan to make.
    • These are especially suited for internal business apps.
    • With an unlocked package, you have a lot of flexibility. Your admins can make changes directly in production in response to emergency change requests because metadata in unlocked packages can be modified in a production org.

Governance


If you have multiple teams working together and delivering different features at same time, then you need to establish governance to avoid technical debt on platform.  
Suppose each team is building different VF pages or installing different manage packages from appexchange, then their may be chances that developer are doing customization instead of referring salesforce standard capabilities. Also they spend additional effort on functionality which may be implemented by other team. Without governance, there are chances of multiple page layouts, duplicate fields or VF pages. 

  • Center of excellence
This team can help to monitor if Salesforce development standards or practices have been followed or not and can also help in reducing the technical debt on platform. This team can emphasis on using Salesforce standard functionality instead on customization. This team can be involved in solution design reviews and can provide feedback before actual development.
  • Change control board
Change control board can help in avoiding duplicates in system. This Committee makes decisions regarding whether or not proposed changes should be implemented. They can raise hand or point out if functionality is already existing in system. This committee can also help in monitoring the system limits and take decisions based on that.


Agile vs Waterfall Methodology

  • Use agile approach if requirements keeps on changing based on end user feedback. This involves having DevOps for rapid testing and development. This is iterative approach in which we deliver features one by one. In this approach we estimate project time line and budget and will not have strict deadlines as requirements may vary based on end user feedback.
  • Use waterfall methodology if project has fixed scope, timeline and budget. Also if requirements are pre-defined and end users are looking for complete product, then opt for waterfall.

Testing

  • Load testing : This is considered as positive test as we monitor application performance with predefined load (concurrent operations).
  • Performance testing: This test is performed to monitor response request time throughput and measuring mean time of application performance under normal conditions. This is also considered as positive test. For this we perform concurrent transaction to measure application performance.
  • Stress testing : This is considered as negative testing. It is similar to load testing but we keep on increasing the load on application till application/server crashes down.
  • Salesforce production is shared environment so stress testing is prohibited by salesforce. Salesforce impose lot of governor limits to avoid this.

Apex Hammer Test

Salesforce runs your org’s Apex tests in both the current and new release and compares the results to identify issues for you. The Hammer means taking every single Apex test that you or anyone else has created and running it twice.
Salesforce uses these results to identify any issues to resolve before the release.
Apex hammer test refer only those test classes which do not have access to org data.  The advantages of creating data silo tests are:
  • Tests run more reliably because they aren’t dependent on data that can sometimes change.
  • Failures from those tests are easier to diagnose.
  • Finding bugs in the Hammer process is easier.
  • Deploying from one org to another is more reliable.
Apex is not alone in running hammer tests.  Visualforce, packaging, Trialforce, and dashboards all go through a similar process.  The Apex process is the most involved, but the general principle of finding potential issues before you do is applied to all of these.


Hope this will help!!!
Best of luck for your exam!!!