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!!!






Sunday, August 11, 2019

Accessing Child Records from sObjects using getSobjects method

Dynamic queries plays very important role when we need to run different SOQL based on different inputs. By using dynamic apex, we can store the output of queries in sObjects list and then can even check if parent record contains any child records. Even if you want to fetch child record information then you can use "getSobjects('relationshipname') method to get child information.

Below is code snippet to get all opportunities and contacts information related to Account:

Hope this will help!!!

Thursday, June 13, 2019

Accessing Parent Field Values from sObjects in Dynamic Queries Using Dynamic Apex

In case of dynamic queries, we often store queries output in sObject and then refer field values. In order to refer field values, we first type cast generic sObject into specific objects like Account, Contact or custom objects as mentioned below:

string qString = 'Select id, name from Account Limit 1';
sObject sb = database.query(qString);
Account acc = (Account)sb;
string accountName = acc.Name;

Suppose we know the field API names then we can utilize the concept of sObject to get field values directly without type casting as mention below:

string qString = 'Select id, name from Account Limit 1';
sObject sb = database.query(qString);
string accountName = sb.get('Name');

So now with the help of sObjects concept, we can access parent field values from child records.

Now consider a scenario in which I have list which stores all field API names which can be used to query opportunity line items. I will generate the dynamic query and will use concept of sObject to access Opportunity fields from sObject which is output of dynamic query.

List<string> fieldAPINamesList = new List<string>{'Id','Opportunity.Name','Opportunity.Partner__r.Name'};
string qString ='Select '+string.join(fieldAPINamesList,',')+ ' from OpportunityLineItem where id=\'00k90000002z4ml\'';
system.debug('****qString:'+qString);
sobject sb = database.query(qString);
//syntax to get OpportunityLineItem Id  value from sObject
string OpportunityLineItemId = string.valueof(sb.get('Id'));
system.debug('******OpportunityLineItemId:'+OpportunityLineItemId);
//syntax to get Opportunity.Name field value from sObject
string OpportunityName = string.valueof(sb.getSobject('Opportunity').get('Name'));
system.debug('******OpportunityName:'+OpportunityName);
//syntax to get Opportunity.Partner__r.Name field value from sObject
//If partner field in opportunity is blank then you will get null pointer exception
string partnerName = string.valueof(sb.getSobject('Opportunity').getSObject('Partner__r').get('Name'));
system.debug('******partnerName:'+partnerName);

Note: While accessing the parent record details in child to parent query, you will get null pointer exception if parent is blank in child record.

I have written an utility method which takes sObject and fieldAPIName as a parameter and returns field value. Please refer below code for reference:

If you run above script in developer console by specifying correct opportunityLineItem Id, then you will see below logs:


Hope this will help!!!

Thursday, June 6, 2019

Fire Platform Events from Batch Apex using Database.RaisesPlatformEvents Interface

With Summer'19 release (API version 44 or later), now it is possible to fire platform events from batch apex. So whenever any error or exception occurs, you can fire platform events which can be handled by different subscriber.

Batch class needs to implement "Database.RaisesPlatformEvents" interface in order to fire platform event.

global class SK_AccountProcessBatch implements Database.Batchable<sObject>,Database.RaisesPlatformEvents{
   //batch logic
}

To understand more about platform events please refer below links

Platform Events : Way to Deliver Custom Notifications within Salesforce or to external Application

Here I will be writing simple batch class which process account records and if any errors occurs during update, then all account record Ids will be published using platform event.

I have created platform event with below mentioned fields:


Below is batch apex code which will fire platform event and I wrote a trigger which will subscribe to platform event.

I have used Database.Stateful interface to store the record ids which are getting failed in each batch execution. In finish method, I am firing platform event with all failed records Ids.

Below is logs generated by trigger which will get executed whenever platform event is fired.


In order to see debug logs for platform events subscription, add a trace flag entry for the Automated Process entity in Setup. The debug logs aren’t available in the Developer Console’s Log tab.

Navigate to SetUp --> Debug Logs --> New
  • For Traced Entity Type, select Automated Process.
  • Select the time period to collect logs and the debug level.
  • Click Save.
I have also created a lightning component which will subscribe to platform events and will display the event message as shown below in snapshot:

Please refer below link to understand how to use platform events in lightning components:

Handling Platform Events in Lightning Components


Hope this will help!!!


Saturday, June 1, 2019

How to Get List of All Child Records for Given Parent Records in .csv File using Apex

If we have lot of child object for a parent object, then it becomes very difficult to find out list of all related records for a given parent. For example, Account and Contact is reference by many standard and custom objects.

Consider a scenario in which Account is parent for more than 50 objects. In this case if we have to check if account record is being reference in any of these child objects, then how we are going to do that.  Its very difficult to add all related list on account page layout or to write SOQL queries to get this information.

If we use nested queries as mentioned below, then we have limit to use only 20 nested queries.

select id, (Select id from Cases),(Select id from Contacts) from Account where Id='0010000xxxxxxx'

In order to overcome these issues, I have written a script which you can run in developer console and you will receive email with .csv file containing all child records for a given parent record.

In below mentioned script, specify the object API name and 15 or 18 digit record id.

After running this script, you will receive .csv file in email as shown below:


If you are getting below mentioned error, while running the script, the make note of below points:


  • This exception can not be handled by try and catch
  • SOQL is not performing well may be because the large volume of data or due to indexing issues on table.
  • Instead of running this script developer console, use batch apex to run this logic. You can create a custom object and first run a script to store all child objects details like relationship name, child object name. Then you can execute the logic in batch class to first fetch all these records from custom object and then fire nested queries by using relation names and store output in variable. Make sure your batch size is not greater than 20 as we have limit of 20 nested queries in SOQL. In finish method write send email code to get .csv file. If you are still getting this error, then keep on reducing the batch size.
Hope this will help!!

Looking forward for your comments and suggestions.



Thursday, May 30, 2019

How to get all Child Objects List along with Relationship Names related to Parent Object using Apex

Sometimes it is required to get the list of all child relationship names in order to identify all related child objects to a parent object.

Dynamic apex helps to find out all related child object. Suppose you want to find all related object for Account then use below code snippet:



You can specify any object API name and run this code snippet in developer console.

You can also use workbench to find out list of child objects. Navigate to Info tab and select Standard & Custom Objects.


Hope this will help!!