Andy in the Cloud

From BBC Basic to Force.com and beyond…

Category Archives: Tools


by 16 Comments

Branch Support for GitHub Salesforce Deploy Tool

If your not familiar, the GitHub Salesforce Deploy Tool will allow you to place a handy button on your GitHub README files to allow for super easy browser based deployment from your repo to a Salesforce org. Up until now it only worked on the master branch, it now supports branches!

GitHubSFDeployBranches.png

The new support for branches, does in fact cover tags and commits as well. Though only branches are defaulted from the button. If you already have the button on your README file, you will find it now magically starts detecting the branch!

ButtonOnABranch.png

Deploy to Salesforce buttons on branches now work!

If your new to the tool, go to the main page and grab the button code and paste it into your README file.  Or if you want a button you can use explicitly in a blog or article you can fill in the fields and generate it from the same page. As you can see the enhancement adds a new ref parameter to the generated URL. This can be a branch name, tag or commit. You can read more about the tool here.

ButtonWithScript.png

Enjoy!

 


by 10 Comments

Introducing the Flow Factory

Flow is a great technology for providing a means for non-coders to build functionality. More so than any other point and click facility on the platform, even Process Builder. Why? Because it offers a rich set of Elements (operations) that contain conditional branching, loop and storage of variables. Along with the ability to read or update any object (API accessible) you like. Its almost like a programming language….

Ironically, like Apex, it is missing one increasingly asked for feature… being able to call another Flow that is not known at the time your writing your calling code. Such as one configured via the amazing Custom Metadata… Basically a kind of Apex reflection for Flow. Often the workaround for this type of problem is to use a factory pattern.

As i highlighted in this prior blog on calling Flow from Apex, the platform does not yet provide this capability to change this please up vote this idea. Well at least not in Apex, as there exists a REST API for this. Meanwhile though back in the land of Apex, it occurred to me when building the LittleBits Connector last year. As workaround i could generate a factory class that would workaround this.

I have created Flow Toolbelt library (GitHub repo here) and package (if you want to install that way) which takes last years solution and lifts it into its own smaller package. The Flow Factory tab discovers the Flows configured in your org and generates the required factory Apex class. If you add or remove flows you need to repeat the process.

FlowFactory.png

Once this has been Deployed you can use code like the following. Passing in the name of your Flow. Note this is a WIP version of the library and needs more error handling, so be sure to pass in a valid Flow name and also at least an empty params Map.

Flow.Interview flow =
  flowtb.FlowFactory.newInstance('TestA', new Map<String, Object>());
flow.start();
System.debug(flow.getVariableValue('Var'));

I think this concept can be extended to allow Flow to run from other Apex entry points, such as the recently added Sandbox Apex callback. Allowing you to run Flow when your Sandbox spins up. Let me know your thoughts, if this is something useful or not.

 

 


by 7 Comments

Working with Apex Mocks Matchers and Unit Of Work

The Apex Mocks framework gained a new feature recently, namely Matchers. This new feature means that we can start verifying what records and their fields values are being passed to a mocked Unit Of Work more reliably and with a greater level of detail.

Since the Unit Of Work deals primarily with SObject types this does present some challenges to the default behaviour of Apex Mocks. Stephen Willcock‘s excellent blog points out the reasons behind this with some great examples. In addition prior to the matchers functionality, you could not verify your interest in a specific field value of a record, passed to registerDirty for example.

So first consider the following test code that does not use matchers.

	@IsTest
	private static void callingApplyDiscountShouldCalcDiscountAndRegisterDirty()
	{
		// Create mocks
		fflib_ApexMocks mocks = new fflib_ApexMocks();
		fflib_ISObjectUnitOfWork uowMock = new fflib_SObjectMocks.SObjectUnitOfWork(mocks);

		// Given
		Opportunity opp = new Opportunity(
			Id = fflib_IDGenerator.generate(Opportunity.SObjectType),
			Name = 'Test Opportunity',
			StageName = 'Open',
			Amount = 1000,
			CloseDate = System.today());
		Application.UnitOfWork.setMock(new List<Opportunity> { opp };);

		// When
		IOpportunities opps =
			Opportunities.newInstance(testOppsList);
		opps.applyDiscount(10, uowMock);

		// Then
		((fflib_ISObjectUnitOfWork)
			mocks.verify(uowMock, 1)).registerDirty(
				new Opportunity(
					Id = opp.Id,
					Name = 'Test Opportunity',
					StageName = 'Open',
					Amount = 900,
					CloseDate = System.today()));
	}

On the face of it, it looks like it should correctly verify that an updated Opportunity record with 10% removed from the Amount was passed to the Unit Of Work. But this fails with an assert claiming the method was not called. The main reason for this is its a new instance and this is not what the mock recorded. Changing it to verify with the test record instance works, but this only verifies the test record was passed, the Amount could be anything.

		// Then
		((fflib_ISObjectUnitOfWork)
			mocks.verify(uowMock, 1)).registerDirty(opp);

The solution is to use the new Matchers functionality for SObject’s. This time we can verify that a record was passed to the registerDirty method, that it was the one we expected by its Id and critically the correct Amount was set.

		// Then
		((fflib_ISObjectUnitOfWork)
			mocks.verify(uowMock, 1)).registerDirty(
				fflib_Match.sObjectWith(
					new Map<SObjectField, Object>{
						Opportunity.Id => opp.Id,
						Opportunity.Amount => 900} ));

There is also methods fflib_Match.sObjectWithName and fflib_Match.sObjectWithId as kind of short hands if you just want to check these specific fields. The Matcher framework is hugely powerful, with many more useful matchers. So i encourage you to take a deeper look David Frudd‘s excellent blog post here to learn more.

If you want to know more about how Apex Mocks integrates with the Apex Enterprise Patterns as shown in the example above, refer to this two part series here.


by 112 Comments

Declarative Rollup Tool Summer Release!

Over the course of the last couple of weeks, i have been focusing my community time on release v2.4 of the DLRS tool. Specifically focusing on some much requested features driven by the community in the the Chatter group.

So lets get stuck in…

Rollup Scheduler Improvements

The ability to run a full (or partial with criteria) recalculate of a rollup on a daily schedule has been in the tool for a few releases now. However up until now the only option was to run it at 2am everyday. It is now possible to change this with this new UI, its a bit raw and basic, but for now it should at least give some more flexibility.

RollupSchedule.png

Support for Merging Accounts, Contacts and Leads

The platform has some special handling for merging Accounts, Contacts and Leads. Especially when it comes to when Apex Triggers are invoked. Basically if your parent object is one of these objects, prior versions of the tool had no awareness of this operation, so rollups would not recalculate. If you are using Realtime or Schedule calculation modes on your rollups. Since the platform does not fire Apex Triggers for child records reparented as a result of a merge.

With this release there are two things you can do to fix this. First when you click the Manage Child Trigger button, you get a new checkbox option to control deployment of an additional Apex Trigger on the parent object. If your upgrading you will need to click Remove then Deploy again, to see this.

ParentTrigger.png

IMPORTANT NOTE: If you don’t feel merge operations are an issue for your use cases you can deselect this option and cut down on the number of triggers deployed. Also if it is only the rollup child object that supports merging, there is no need to deploy any additional triggers and the tool does not show the above checkbox option.

Secondly you need to setup the RollupJob as an Apex Scheduled job (under Setup > Apex Classes), even if you don’t have any Schedule Mode rollups. This is due to the fact that due to a platform restriction, the tool cannot recalculate rollups realtime during a merge operation. So it can only record that they need to be recalculated. It does this via the tools scheduled mode infrastructure, by automatically adding records to the Lookup Rollup Summary Schedule Items object. Note that you don’t need to change your rollups from Realtime to Scheduled mode for this to work, only schedule the job.

Support for Archived / Deleted Records via the All Rows Setting

Salesforce archives Tasks and Events after a while. If you have rollups over these child objects you can enable the Aggregate All Rows checkbox. This will ensure your rollups remain accurate even if some records have been archived. Note this also will apply to records in the recycle bin. For upgrades (if your not using the Manage Lookup Rollup Summaries tab), you will need to add this field to your layout to see it.

AllRows.png

Row Limit for Concatenate and Last Rollup Operations

If your using the Last or Concatenate operations, you can define a limit as to how many child records are actually considered when calculating the rollup. This is useful if your using Concatenate into a fix length field for example. When upgrading you need to add the new Row Limit field to your layout if your not using the swanky new Manage Lookup Rollup Summaries tab.

RowLimit.png

Improved House Keeping for Scheduled Mode

If your are using rollups with their Calculation Mode set to Scheduled. The tool records parent rollup records to be later recalculated by the RollupJob Apex Scheduled job. In past releases if through merge or other operation the parent record was deleted before the next scheduled run. Then records would sit in limbo in the Lookup Rollup Summary Schedule Items object, being processed and erroring over and over. These will now be cleared out and there is no upgrade actions you need to take for this.

Summary

Thanks for everyones support for this tool, i hope these changes help you go further with clicks not code! Though as reminder please keep in mind the best practices and restrictions listed in the README. If you have any questions you can either post comments on this blog or use the Chatter Group. The Chatter Group is a great place to get your query seen by a broader group of people who are also diligently supporting the tool as well!

You can find releases of the tool here.


by 17 Comments

Introduction to the Platform Action API

shutterstock_159003926.jpg

Actions are Salesforce’s general term for tasks users can perform either through buttons throughout various UI’s on desktop, mobile, tablet etc or in fact via non-UI processes such those built via via Process Builder or Automation Flows.

Actions are about “getting things done” in Salesforce. They encapsulate a piece of logic that allows a user to perform some work, such as sending email. When an action runs, it saves changes in your organization by updating the database. More here.

Over the years we’ve had many terms and ways to define these. Custom Button and Custom Link are perhaps the most obvious ones, which i’ve covered here in the past. Quick Actions (previously Publisher Actions) and more recently we’ve had Action Link‘s, which i covered in a past blog. Then of course the Standard Buttons, Edit, Delete, Follow, Submit for Approval etc provided by the platform. Such actions appear in various places Record layouts, List Views, Related Lists, Chatter and more recently Flexi Pages (aka Lighting Pages).

You might wonder then, if you had the task as developer to build your own UI or tool that wanted to expose some or all of the above actions, it would be quite a challenge to find them all. Indeed in some cases you may have had to resort to URL hacking to invoke some of them. Well worry not no longer, Salesforce’s clever architects now have you covered! Enter a new virtual SObject known as PlatformAction! Before we get onto what exactly virtual means, lets review some Actions and some SOQL queries…

Consider this Account Record detail page in the Classic (or Aloha) UI…

PlatformActionAccount.png

Note down your record ID and use it in a query like the one below…

SELECT DeviceFormat, Label, Type, Section,
       ActionTarget, ActionTargetType, ActionListContext
  FROM PlatformAction
  WHERE ActionListContext = 'Record' AND
        SourceEntity = '001B000000D2V0n' AND
        Section = 'Page' AND
        DeviceFormat = 'Aloha'

In Developer Console you should see something like this…

PlatformActionQueryResults1.png

Pretty cool huh!? Check out the ActionTarget field, for the Standard Button records, thats the URL you can place on your UI’s to invoke that action, simple as that! Better still this is a supported way to get it, no more URL hacking! Now lets add a couple of Custom Buttons and re-run the query…

PlatformActionAcount2.png

We now see CustomButton records appear…

PlatformActionQueryResults2.png

This next query reveals actions shown on a List View. I did note Custom List View buttons that require record selection did not appear however. I suspect this is due to them requiring more than a simple HTTP GET URL to invoke.

SELECT DeviceFormat, Label, Type, Section,
       ActionTarget, ActionTargetType, ActionListContext
  FROM PlatformAction
  WHERE ActionListContext = 'ListView' AND
        SourceEntity = 'Account' AND
        Section = 'Page' AND
        DeviceFormat = 'Aloha'

Other observations..

  • Prior to Summer’16 (out in preview as i write this), Apex SOQL was not supported, only REST API SOQL. This is due to a limitation with the internally applied LIMIT keyword. This has now been resolved in Summer’16, so Apex SOQL now works!
  • SourceEntity can also be given an SObject API name, e.g. SourceEntity = ‘Account’, the result here are object level buttons, like New or those you add to the MRU page.
  • DeviceFormat field value matters, if you leave it off, it defaults to Phone. Thus some actions will be missing from those in Desktop (Lightning Experience) or Aloha (Classic). I eventually found Custom Buttons using Visualforce pages that didn’t have the Lightning Supported checkbox set didn’t appear when querying with the Phone device type for example.
  • User context matters, actions returned are user and configuration sensitive, meaning the record itself, record type and associated layout all contribute to the actions returned. Custom Buttons for example need to be on the relevant layout.
  • Label and Icon information, there are also fields that allow you to render appropriate labels and icons for the actions.
  • Related List actions, you can also retrieve actions shown on related lists, search for RelatedList in the help topic here.
  • Describe actions? You will notice some actions have an ActionTargetType of Describe? These are invoked via an API, something i will cover in later blog.

So lets discuss the “virtual SObject” bit!?!

Your probably wondering what a virtual SObject is?

Well my best guess is its an SObject that is not backed by physical data in the Salesforce database. If you check the documentation you’ll see fields just like any other object and it supports SOQL (with some limitations). My thinking is the records for this object are dynamically generated on demand by doing all the heavy lifting internally to scan all the various historic places where actions have been defined.

Thank you Salesforce architects, this is now my #1 coolest Salesforce API!

Whats next?

  • For starters, no more URL hacking of those standard pages, no excuses now!
  • Helper class or Visualforce and/or Lighting component for actions?
  • Explore the Force.com Actions Developer Guide


by 18 Comments

GitHub Salesforce Deploy Tool Lightning Edition

A recent discussion on Twitter around sharing Salesforce configuration between admins has motivated me to revisit this tool. Before getting into anything major (watch this space). I decided to get back into the tools code by addressing a few outstanding maintenance tasks, enhancements and bug fixes, as well as treating it to a face lift!

LightningGitHubSFDeploy.png

As some of you may have noticed the tool has now adopted the Salesforce Lightning Design System look and feel. This new version is not just cosmetic, its also addressed some key enhancements and bug fixes…

LightningGitHubSFDeploy2.png

In keeping with the Lightning principles, this release makes the Deploy to Salesforce button (example shown below), even easier to place in your repository README files with less configuration required. The button will now automatically detect the GitHub repository. Which is useful if you Fork a repository into your own account or rename it, you no longer need to change the README file. The button code is now also smaller.

LightningGitHubSFDeployButton.png

IMPORTANT NOTE: This only works if your placing the button code in a GitHub README file. If your planning on using the button on a blog, article or wiki etc tick Use Specified Owner and Repository checkbox to have the specified repository details encoded into the button code as before.

This release has now also addressed issues preventing use with repositories that have Reports or Lightning Components in them. So you can now use the tool to deploy your favourite open source Lightning Components!

Finally if you have any private repositories, an improvement around the error handling in this area has also been made. Thanks to some great code contributions from Moti Korets and  Nathan Kramer for the whole GitHub private repository support! Thanks guys!

 

 


by 6 Comments

Dynamically Calling Flows in Apex

During last years fun with IoT and the LittleBits devices, i developed a package imaginatively called Salesforce LittleBits Connector. My aim for that connector was to allow none coders, to have some fun with IoT and Salesforce. Instead of requiring Apex code to control devices and respond to events i wanted to allow the user to leverage Flows. When building it a previously observed limitation with the Apex integration with Flow surfaced again…

Whats the problem?

While Apex can create a Flow that is known at the time code is written, it cannot dynamically create a Flow determined at runtime. My blog entry Calling Flow from Apex goes into what is currently possible and highlights this restriction towards the end. This idea proposes that Salesforce adds something like the following to Apex…

// Create the Flow named in the userDefinedFlow variable
Flow.Interview.Interview anyFlow =
    Flow.Interview.newInstance(userDefinedFlow, flowParams);
// Run the Flow
anyFlow.start();
// Retrieve a value from one of its variables
String outputValue =
    (String) anyFlow.getVariableValue('outputVarName)';

Current solutions… 

Salesforce describes the current options for launching Flow here, one of which is indeed via its REST API, which if called from Apex would provide the facility we are looking for here, however i wanted to avoid HTTP callout and the limitations that entails. With the Salesforce LittleBits Connector i solved the problem using an Apex interface, the utilisation of the factory pattern and a Tab that provides a facility to manage the code generation of a Flow factory class.

FlowFactory.png

The following code snippet from the tool shows how the Flow factory approach works. It uses Apex type.forName to create an instance of the above generated class (from the unmanaged namespace of the org).

// Get a Type reference to the Flow Factory class
Type typeFactory = Type.forName('', 'lbc_LittleBitsFlowFactory');
if(typeFactory==null) {
	System.debug(FlowFactoryClass + ' class not found.');
	return;
}
// Create an instance of the Flow Factory
ILittleBitsFlowFactory flowFactory = (ILittleBitsFlowFactory) typeFactory.newInstance();
// Create an instance of the Flow via the factory newInstance method
Flow.Interview flow = flowFactory.newInstance(flowName, flowParams);
// Start and interact with the Flow as normal
if(flow!=null)
	flow.start();

The interface looks like this…

// Interface implemented by the generated Flow Factory class
global interface ILittleBitsFlowFactory {
	Flow.Interview newInstance(String flowName, Ma&lt;String, Object&gt; params);
}

The key with this solution is the Tab above that provides a means for the Admin user to dynamically create or refresh the lbc_LittleBitsFlowFactory Apex code which has access to the specific Flows. This class lives as an unmanaged class in the org. Before we look at how the Tab works, lets take a closer look at what it generates in the org.

/**
 * Auto Generated and Deployed by the LittleBits Connector package (lbc)
 **/
global class lbc_LittleBitsFlowFactory implements lbc.ILittleBitsFlowFactory {
    public Flow.Interview newInstance(String flowName, &lt;String, Object&amp;amp&gt; params) {
        if(flowName == 'FlowTest')
            return new Flow.Interview.FlowTest(params);
        if(flowName == 'HandleKioskActivity')
            return new Flow.Interview.HandleKioskActivity(params);
        if(flowName == 'HandledHandshake')
            return new Flow.Interview.HandledHandshake(params);
        return null;
    }
}

Note: I found that i needed the class to be marked as global at the time, i suspected this might have been that the packaged code was not Aloha status. If your not packaging your solutions code, this your code runs in the unmanaged namespace, you’ll find that you don’t need global and public will be fine. The Tab also generates an Apex Test for the above code as well, to ensure code coverage is satisfied.

The Tab itself scans the configurations of the tool for references to Flow names, in this case it was LittleBits Device Subscriptions, it could also utilise the Apex Metadata API listMetadata as well. The former approach does keep the generated code focused on the Flows needed by the tool. The page then uses the Apex Metadata API to deploy the generated code to the org. If you want to review this code in more detail take a look at ManageFlowFactoryController and the manageflowfactory page.

Summary

I find Flow to be a hugely liberating technology for creating solutions without requiring coding skills on Salesforce. I hope to wrap the above solution in a standalone open source solution that contains a dynamic Flow API and the Tab above, such that others can start to integrate Flow into other tools as I did with the LittleBits connector. Meanwhile please enjoy reviewing the approach in its current form and let me know your thoughts!

Note: Key to this solution is the use of the  Apex Metadata API to deploy the factory code. I have learnt recently that Salesforce are increasing security around Apex execution invoked from Lightning Components (via @AuraEnabled annotated methods). The implication of this is that UserInfo.getSessionId does not return an API capable Session Id. This effectively blocks such code from calling any Salesforce API’s (including Metadata API) via Http callouts using the users Session Id. I’ll be looking at means in the future to use oAuth to formalise access like this.

Update: See blog Flow Factory.


by 24 Comments

Rollups and Cross Object Formula Fields

I’m constantly amazed at the number of varied use cases folks in the Chatter Group are applying to the Declarative Lookup Rollup Summary tool these days. This short blog highlights a particular use case that seems to be on the increase. To resolve it i reached out for additional help in the solution from Process Builder, this is the story…

Background: What causes a Rollup to recalculate?

The default behaviour of the rollup tool is to look for changes to the field your rolling up on, the one specified in the Field to Aggregate field. In addition you can list other fields for it to look at via the Relationship Criteria Fields field, which as the name suggests is also important information if you’ve used rollup criteria. However its also important if the field your rolling up on is a Formula field. In the case of formula field rollups the platform doesn’t inform the tools Apex Trigger of changes to these. So it cannot directly monitor such fields and to resolve this must instead be told explicitly about the fields that are referenced by the formula expression. So far so good…

Challenge: Rollups over Cross Object Formulas?

A challenge however arises if you’re wanting to do a realtime rollup based on a formula field that references fields from a related record, a cross object formula! In this case how does the rollup tool know when changes are made to related records?

One solution to this is to switch to schedule mode by clicking the Schedule Calculate button on the rollup. For realtime rollups, its potentially feasible to enhance the tool to deploy triggers to related objects and bubble up knowledge of field changes to the cause a recalculate of the rollup on the child object… However before we resort to more code (even in the tool) lets see what we can do with the declarative tools we have already today…

Example Use Case

The following schema diagram shows a simplified mockup of a such a challenge i helped a community member out with in the tools Chatter Group.

FormulaRollupUseCase.png

Here is the scenario assumptions and break down…

  • For whatever existing reasons the above is NOT a Master Detail relationship
  • Rollup needed is to Sum the Quote Line Item > Amount into the Quote > Total field.
  • The Quote Line Item > Amount field is a Formula field, which is a cross object formula pointing to the related Widget > Total field.
  • The Widget > Total field is itself a Formula field, in this simplified case adding up the values of Widget > A + Widget > B + Widget > C.
  • Whenever changes to the Widget > A, Widget > B or Widget > C fields are made we want the Quote > Total field to be recalculated.

Here’s the rollup summary definition between Quote and Quote Line Item…

ForumlaRollupDLRS.png

While the above works if you use Calculate (one off full recalculate) or Schedule Calculate (daily full recalculate) buttons. Our issue arises in the general use of the Realtime mode. Since the tools triggers see nothing of the changes users make to the Widget fields above, realtime changes are not reflected on the Quote > Total rollup. This is due to the aforementioned reason, since we are using a cross object formula.

NOTE: The Calculate Mode pick list also has a Schedule option, this is a more focused background recalculate, only recalculating effected records since the last run, rather than Schedule Calculate button which is a full recalculate every night. So be aware if your using this mode that the problem and solution being described here also applies to Calculate Mode when set to Schedule as well. As it uses the same field monitoring approach to queue records up for scheduled recalculation.

If your fine without realtime rollups go ahead and use the Schedule Calculate button and at 2am each morning the Quote > Total amount will catchup with any changes made to the Widget fields that effected it, job done!

Solution: Shadow Fields and Process Builder

So when considering the solution, i did consider another rollup between the Widget and Quote Line Item to start to resolve this, thinking i could then put the result in field that the Quote Line Item > Quote  rollup would see change. However this was quickly proved a poor consideration as the relationship between Widget and Quote Line Item in this use case is the wrong way round, as Quote Line Item is the child in this case, doh! In other use cases, i have had success in using nested rollups to get more complex use cases to fly!

Shadow Field?

AmountShadowFieldEither way i knew i had to have some kind of physical field other than a Formula field on the Quote Line Item object to notify the rollup tool of a change that would trigger a recalculate of the Quote > Total. I called this field Amount (Shadow) in this case, i also left it off my layout.

NOTE: I’ve made the assumption here that for whatever reason the existing cross object Formula field has to stay for other reasons, if thats not a problem for you, simply recreate Quote Line Item > Amount as a physical field and as you read the rest of this blog consider this your shadow field.

I then changed my rollup definition to reference the Amount Shadow field instead.

ChangesToRollup

NOTE: If you managed to switch the field type of your Amount field from a Formula to a physical Number field as noted above you don’t need to do this of course.

Process Builder to update your Field to Aggregate

Next i turned to Process Builder to see if i could get it populate the above Amount (Shadow) field on Quote Line Item, as users made changes to Widget fields. Leveraging the child parent relationship between Quote Line Item and Widget. Here is the setup i used to complete the solution!

FormulaRollupProessBuilder1.png

FormulaRollupProessBuilder2.png

FormulaRollupProessBuilder3.png

Summary

Its worth noting that if the relationship between Quote Line Item and Quote was Master Detail, you can effectively now of course use standard platform Rollup Summary Fields without needing the rollup tool at all. You may think me bias here, but not at all, i’d much rather see a fully native solution any day!

Regardless if this use cases fits yours or not, hopefully this blog has given you some other useful inspiration for further rollup and Process Builder combo deals! Enjoy!


by Leave a comment

Packaging and Installing Rollups

Since v2.0 of the Declarative Rollup Tool, it is now possible to use Custom Metadata to store rollup configurations. Not only does this make it easy to transfer those you have setup in Sandbox via Change Sets, you can also use Salesforce packaging to capture those you’ve created and install them over and over into other orgs, like a reusable Change Set!

InstallRollups

Create and set up your Packaging Org

To do this, you need a Developer Edition org from Salesforce, this will act as your master org for your common rollup definitions. Here you can install the rollup tool package itself as minimum. Then also create common fields or objects used by your rollups if you wish. You can also install any other packages, such as the NPSP packages. Basically prepare and test everything here as you would normally in Sandbox or Production.

DESignup

Creating your Package

Under the Setup menu navigation to Create and then Packages. Create a new Package with an appropriate name. Click Add to components, components are anything from Custom Objects, Fields, Apex Triggers and Apex Tests to the Rollup definitions themselves. As a minimum you will need to add the following components for rollups.

  • Apex Classes for the rollup/s (starting dlrs)
  • Apex Triggers for the rollup/s (starting dlrs)
  • Lookup Rollup Summary definition/s

The platform adds a few other dependent things as you can see in the screenshot below, but don’t worry about these. You should have something like this…

PackagingRollups

Tip: After creating your rollups, go to Setup and Custom Metadata, and find your rollup definition, edit it and locate the Protected checkbox, then hit Save (at present this checkbox is not shown in the custom UI for rollups). This checkbox prevents users or other admins from changing your rollup definition once installed. You also need to use the managed package route though, as described below.

Choosing Unmanaged or Managed Packages

This choice depends on if you want to manage several updates / releases to your rollups over time, adding or updating as you improve things. An umanaged package is basically like just installing a template of your rollups, once installed thats it, they are no longer linked to your package. If however you want to install updates to them and/or stop people from editing your rollups (see protected mode above), you want a managed package.

Setting a namespace for your Managed Package

If you decided you only want an unmanaged package, skip this bit. Otherwise on the Packages page, under Setup then Create. Click Edit button and follow the prompts to enter a namespace, this is a short mnemonic that describes your package, like a unique ID. Once set it cannot be changed. Next find your Package detail and click Edit, selecting the Managed checkbox on hitting Save.

Uploading your Rollup Package!

PackagesRollups

This process basically builds your installer, by actually placing a copy of what you’ve done in the AppExchange servers. All be it as a private listing. This gives you an install link to use over and over as much as you like. Install it in the sandbox and production as needed.

Click on your package and then the Upload button, give it a name and version of your choose. Be sure to select the Release mode, in most cases for this packaged content worrying about Beta vs Release mode is not a concern. Press Upload and wait.

PackageUpload.png

RollupPackageSummary

Rinse and Repeat?

Keep in mind if you went with the managed package route. You can go back to your packaging org, make some improvements, add more rollups etc, then repeat the upload process to get a new version of your package. Simply then go to any existing org with your prior release installed and upgrade.

NOTE: To ensure your rollup definitions are upgraded they must be marked as protected. If you don’t care about this and only want new rollups to be added, retaining subscriber (installed org) changes, don’t worry about Protected rollups.

 

 


by 33 Comments

Declarative Lookup Rollup Summary Tool and Custom Metadata

Back in Dreamforce 2015, i told the audience in a session dedicated to Custom Metadata that i estimated it would take around 5 days to perform the retro fit from Custom Object to Custom Metadata. Well i’m pleased to say i have come in a little under that, and also retained support for using Custom Object’s to store rollup definitions for now.

“Custom Metadata is like Game of Thrones, its addictive, great value for money and I just keep wanting more of it!”

In this blog i’ll talk about what support for Custom Metadata means for users of the tool and also a bit about how technically the retrofit was coded.

DLRS Manage Lookup Rollup Summaries Tab

Before getting into the coding side, lets quickly discuss the new feature and what you can expect…

What is so good about Custom Metadata then?

Well if you have not heard by now, its basically a huge time saver for anyone using apps that have adopted it. As the configurations you make are no longer treated as data but a metadata.

What that means is like other configurations you make under the Setup menu, your rollups in this case are treated like any layout, Custom Field, Validation Rule, Flow etc you have also added, when it comes to migrating to production via Change Sets or building out an extension package and packaging rollups. In addition if your refreshing a configuration only Sandbox, your rollups get copied over as well! No more rekeying rollups or using Data Loaders to transfer them.

If you don’t want to take my word for it, take a look at what Aaaron, Platform Product Management Director at Salesforce, has to say!

Install vs Upgrade

If your familiar with the tool but installing for the first time in a new org you’ll notice some changes to the default tabs (as shown above), though worry not, the old tabs are still present. So if you’d rather catchup with this stuff later just continue as normal setting up your rollups via the Lookup Rollup Summaries tab.

If your upgrading things will remain the same and you’ll have to go to All Tabs to find the new tab above. When you select the new tab you will be presented with a small info message, a link to the old tab and a means to dismiss it once read from appearing again in the future.

DLRS Custom Metadata Tab Info

Tip: You can edit the Declarative Lookup Rollup Summaries app tabs under Setup to remove the new tab and replace with the old until your ready

Why a new Tab and not the native Custom Metadata UI?

The platform provided UI for Custom Metadata is for sure a much appreciated addition, with Layout support its certainly wins out over Custom Settings for sure! In this case however I still found myself wanting in terms of the user experience…

When editing Custom Metadata based rollups I wanted two core peaces of functionality currently available when using the Custom Object based UI. Mainly validation (the existing Apex Trigger / Domain logic) to check field names, allowed activation etc and also make available the various buttons to manage the child object trigger and start/schedule calculations. So, as per the info message above, you can use the native Custom Metadata Types under Setup if you wish, but be advised for now at least, you’ll be bypassing validation.

The design is based on my earlier proof of concept described in this blog.

Does the new tab do all the stuff the old one does?

Almost! Take a look at the Pilot limitations section (see v2.0 release) in the README.

Can i mix and match between using this new feature and existing?

Yes you totally can. Just make sure if you copy over an old rollup to deactivate it once you activate the Custom Metadata based one to avoid duplicate processing.

Is there a means to automate copying my old rollups over to Custom Metadata?

Not currently. This is possible and something i wanted to build for this release, i just ran out of available time, so is now on the backlog as a future enhancement.

I see this is Pilot, are there any known limitations?

Take a look at the Pilot limitations section (see v2.0 release) in the README.

How did you go about coding this retrofit to Custom Metadata?

The Apex Enterprise Patterns and Separation of Concerns most definitely helped me perform the update here. Especially as i wanted to effectively support two storage options, that shared the same fields, but leave the core functionality intact.

If you review the GitHub History around the few days i was working on this (22nd to 24th) you can see more or less that i took the following approach. Also after each set of changes ensuring all unit tests where still working was key.

  1. Created the Custom Metadata object, as per the approach i took in my original proof of concept, this is mostly a copy paste from the Custom Object with some tweaks.
  2. Create a Apex wrapper class around the Custom Object and Custom Metadata representation of the rollup definition, RollupSummary class.
  3. Updated the Selector to return RollupSummary lists instead of Custom Objects. At this stage i just wanted to complete a sweep to address compilation issues (primarily in the Service layer). I had not plumbed in querying for Custom Metadata yet.
  4. Decoupled tracking the Calculation Job Id from the rollup definition (this after all is operational information) and created a new Custom Object to track this, that both modes would use.
  5. Updated the Domain class to support both storage options by utilising the RollupSummary wrapper class within its core logic, to retrieve field values and set field errors etc. Thus the Domain class logic has been abstracted away from the underlying storage type. Apex Trigger behaviour is totally unaffected.
  6. Developed the new UI based on the proof of concept from my earlier blog. Some new RollupService methods also leveraged the CustomMetadataService to perform CRUD operations on Custom Metadata Objects via the Salesforce Metadata API also highlighted in the same blog.
  7. New Service methods have been added to expose operations to callers such as the new UI controller above. These methods also delegate to the Domain class onValidate methods to ensure the same validation as applied to the Custom Object via its Trigger is reused consistently.

Summary

Custom Metadata is like Game of Thrones, its addictive, great value for money and I just keep wanting more of it!