gokubi.com

My post on Friday spawned some great discussion, even over the Labor Day weekend. If you were off enjoying summer’s last gasp, go back and check it out. In this post, I want to follow up on that and try to take the Apex architecture discussion to the next level of depth.

As I’ve said many times on this blog, I’m not a computer scientist, so I’m backing into architecture and often the concepts from CS-101 are new to me. I know I’m not the only one, so I’d like to make explicit some of the assumptions that top-notch developers are making every day. I surely am not an expert, and love to have developers set me straight–life is about continuous learning.

I’m going to lay things out as I understand them–if you think I’m making poor assumptions, please comment and set me straight. Also know that one of the reasons I love coding is that it is a creative act. It’s an amazing combination of a highly analytical process and one of inspiration and experimentation. I bet most programmers love that aspect of the job, and so I don’t believe there is a right way to do things, and I hope this may help to unleash creativity, rather than be seen as laying out any kind of Apex dogma that must be followed for fear of wearing the scarlet ‘no software’ mark on your breast.

#1: How hard should you work to have your triggers be absolutely minimal?

I’ve written a bunch of Apex code and also gotten to maintain Apex code written by others. I think writing software for maintainability should be one of the top goals of all coders. I think the most maintainable way to write Apex triggers is to have as little logic in them as possible. If you are trying to figure out how some code works, or doesn’t work, it’s a lot easier to know that the trigger can safely be ignored because it’s only job is to call the class methods that get things done.

But how hard should we try to do that? Should we make sure our trigger has no logic in it at all? If so, it could look something like this:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {
    MyObjectClass triggerSet = new MyObjectClass(Trigger.new, Trigger.old, Trigger.isBefore, Trigger.Context);
    triggerSet.process();
}

This signature would only have to change if we decide to have this trigger fire in different contexts, like UNDELETE. Of course, it’s not possible now, because there is no Trigger.Context to pass the enum value of the DML context. But, if Jon gets his way and this enum value is created, we have minimized the trigger to 2 lines of code.

But I think there is an efficiency hit. We’re going to instantiate the MyObjectClass no matter what the trigger set includes. If we only want to process records when a certain value changes, wouldn’t it be more efficient to move some logic to the trigger, and only instantiate the object if some of the records in the trigger set need to be processed?

Or is it a negligible difference we shouldn’t worry about?

#2: When should we use static methods vs. object-oriented design?

The trigger above is object-oriented design where an object is instantiated and variables and methods exist for that instance of the object. But the trigger could be written this way too:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {
    boolean success = MyObjectClass.invoke(Trigger.new, Trigger.old, Trigger.isBefore, Trigger.Context);
}

So which is better? That’s something I’ve never been clear on–George made some great comments on my previous post along these lines.

The static method approach seems to make sense when your methods are straight-forward and you aren’t trying to maintain context across a number of actions. I like static methods for “utility” type functions:

utilities.getRecordTypeName(Id recordTypeId);

utilities.submitMyObjectForApproval(List my Objects);

I personally like the object-oriented approach when invoking a trigger. I think it makes sense to instantiate the object that is going to handle the trigger set, and then kick that off with various methods based on the context and timing of the invocation. It seems to me that writing the code to collect all the data from the trigger is best written once, in the constructor. Here’s some pseudocode for a such a class:

public class MyObjectClass {
     public MyObjectClass()
     {
     }

     public boolean triggerIsBefore;

     public enum context {Insert, Update, Insert, Upsert}

     public context contextPassedFromTrigger;

     public List<MyObject__c]]> triggerOldSet = new List<MyObject__c]]>();

     public List<MyObject__c]]> triggerNewSet = new List<MyObject__c]]>();    

     public MyObjectClass(MyObject__c[] myObjects, MyObject__c[] myOldObjects, boolean isBefore, context triggerContext)
     {
          triggerIsBefore = isBefore;
          contextPassedFromTrigger = triggerContext;

          triggerOldSet = myOldObjects;
          triggerNewSet = myObjects;
     }

     public process()
     }
          // BEFORE INSERT
          if (contextPassedFromTrigger==context.Insert&&isBefore)
          {
               someBeforeInsertMethod()
          }

     {

}

The main difference between static and object-oriented functionality is that you can have multiple independent instances of an object, but not of a static variable. So, if you wanted to deal with 4 different opportunities at once, and maintain data or variables for each and then do some processing, object-oriented is probably the way to go.

Each trigger invocation is it’s own universe. scope-wise, so you don’t have to worry about static invocations conflicting across trigger invocations.

#3: What should go in a static Utils class?

I like object oriented design, and I always compliment that with static classes for “utility” type methods and variables. I think each module of functionality you write should have it’s own utility class that services the other classes you’ve got in that module. I gave the example of the getRecordTypeName() method. Also, all your references to Custom Labels and other strings can be placed in this Utils class, and then they can be accessed statically from your other methods.

#4: What are the limits of class proliferation?

This is a tough one. Let’s say I’ve got some complex functionality. It wouldn’t be at all out of the realm of possibility to have the following:

MyProcess.trigger – my trigger to handle DMLs
MyProcessClass – my main class for handling the trigger
MyProcessUtils – my utils class supporting all this functionality
MyProcessException – a class to extend the exception class for this functionality
MyProcessTest – tests supporting all this code
Other classes for functions that should be instantiatable on their own
VisualForce controllers for any necessary UI

With complex functionality it can get to be a lot of files. So how is this balanced with maintainability? Aren’t more files and more dependencies harder for a maintainer to track down?

It is true that the more classes you’ve got, the harder it will be for someone to find everything and get their head around it. Naming conventions are key to finding related functionality. Everything I write that is related to this process will be started with ‘MyProcess’. Things can get confusing where processes meet and overlap–there isn’t anything we can do about that other than document things well with process maps and other tools.

I think that while there may be a lot of classes in this architecture, and findability my suffer, changability can be enhanced. By encapsulating key functions in their own classes or in well-written methods in existing classes, changes can be more easily made. One thing I’ve learned about writing code is to ‘encapsulate that which is likely to change.’ In the short-term that may seem like a lot of infrastructure for relatively simple code, but when it needs to change it may be a lot easier.

So my main takeaways from this foray into thinking about Apex architecture are:

1. Move most of your logic out of Apex Triggers and into Apex classes. Don’t stress out if your Triggers have some logic in them, but the less the better in most cases
2. Decide where you fit on the spectrum between everything static and everything object oriented, and then be consistent. Maintainability will suffer if you’re changing up all the time for similar functions
3. Use a static utilities class, and be mindful about what goes in there
4. Don’t stress out about class proliferation as long as your doing it to encapsulate that which may change later, and aren’t forgetting about making things finadable

I’ve been writing Apex triggers for a while, and recently I ran across two ways to architect triggers that are different from how I used to do things. Both methods have one main benefit–they push all your logic to your classes, and allow the trigger to do just one job–invoke code on data change.

Here’s a trigger architected the first way:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {

    if(trigger.isBefore){
        if(trigger.isInsert){
            MyObjectInsertBefore myInsertBefore = new MyObjectInsertBefore(Trigger.new);
        }
        if(trigger.isUpdate){
            MyObjectUpdateBefore myUpdateBefore = new MyObjectUpdateBefore(Trigger.old,Trigger.new);
        }
    }

    if(trigger.isAfter){
        if(trigger.isInsert){
            MyObjectInsertAfter myInsertAfter = new MyObjectInsertAfter(Trigger.new);
        }
        if(Trigger.isUpdate){
        	MyObjectUpdateAfter myUpdateAfter = new MyObjectUpdateAfter(Trigger.old,Trigger.new);
        }
    }
}

As you can see from the trigger, all that we’re doing is invoking the correct class based on the starting criteria–are we an insert or an update, and are we before or after? We’ve got a separate class for each of the four cases.

Here’s what two of those classes might look like:

public class MyObjectInsertBefore {

	//create your variables and data structures

    //constructor
    public MyObjectInsertBefore(){

    }

    //constructor accepting a list of myObjects
    public MyObjectInsertBefore(MyObject__c[] myObjects){
        //call whatever methods you need to get the job done
        someMethod(myObjects);
        .
        .
        .
    }
}

public class MyObjectUpdateBefore {

	//create your variables and data structures

    //constructor
    public MyObjectUpdateBefore(){

    }

    //constructor accepting a list of myObjects
    public MyObjectUpdateBefore(MyObject__c[] myOldObjects,MyObject__c[] myNewObjects){
        //call whatever methods you need to get the job done
        someMethod(myOldObjects,myNewObjects);
        .
        .
        .
    }
}

Key to making this efficient is to have shared methods in a MyObjectUtil class, so that similar operations can be reused across your classes.

Here’s a trigger invoked the second way:

trigger MyTrigger on MyObject__c (before insert, before update, after insert, after update) {

	public enum triggerAction {beforeInsert, beforeUpdate, afterInsert, afterUpdate}

    if(Trigger.isInsert && Trigger.isBefore){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.beforeInsert);
    }
    if( Trigger.isAfter && Trigger.isInsert ){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.afterInsert);
    }
    if(Trigger.isUpdate && Trigger.isBefore){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.beforeUpdate);
    }
    if( Trigger.isAfter && Trigger.isUpdate ){
        MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.afterUpdate);
    }
}

This trigger sends the old and new sets over to a class and passes the way that this was invoked via an enum value (look up enum in the Apex docs if you haven’t used them–I had to). There is only one class, and then the class sorts out what should happen based on the data:

public class MyObjectClass {

	public MyObjectClass()
	{
	}

	public enum triggeredAction {beforeInsert, beforeUpdate, afterInsert, afterUpdate}

	public MyObjectClass(MyObject__c[] myObjects, MyObject__c[] myOldObjects, triggeredAction ta)
	{	

		// BEFORE INSERT
		if (ta==triggeredAction.beforeInsert)
		{
			someBeforeInsertMethod()
		}

		// BEFORE UPDATE
		if (ta==triggeredAction.beforeUpdate)
		{
			someBeforeUpdateMethod();
		}

		// AFTER INSERT
		if (ta==triggeredAction.afterInsert)
		{
			someAfterInsertMethod()
		}

		// AFTER UPDATE
		if (ta==triggeredAction.afterUpdate)
		{
			someAfterUpdateMethod();
		}

	}
}

You can see that you’re basically accomplishing the same thing–getting the class to invoke the right methods based on the invocation, but that we’re doing it in two different ways. In the first example, we’ve got a proliferation of classes, and each class is very simple. In the second example, we’ve got one class that is more complex as it has to handle many types of invocation.

I ran across the second example in the spring and really liked it. Then I ran across the first example last month and now it’s my favorite. I’m going to try to write new triggers that way and see how they go.

Thanks to Matt and Mike for architecting your code in these really interesting ways! I hope you, like me, love seeing how other people do things–it can really improve the way you code so very quickly.

I want to show you a quick and easy way to take live data from Salesforce.com and post it on your website using Salesforce Sites. You can see lots of hard-core examples of how to use sites. Those are cool, absolutely no doubt. People are building amazing things.

There also are opportunities for very targeted uses of Sites. With these micro-sites, the investment-to-value ratio can be really high. Here’s an example of one such use case.

The Use Case

A nonprofit wants to have a page on it’s website acknowledging all sponsors who supported events in 2007. They want a simple list of organizations, leaving out any who have asked not to be thanked publicly.

The Data

Sponsorships are tracked as Opportunities connected to the relevant Account. Here’s the Opportunity related list from the relevant Account:

I have created a rollup summary field on the Account to sum up all Opportunities from 2007:

And I’ve created a checkbox to flag Accounts that want to stay anonymous. You can see both fields on the account detail page:

The Display

I want to show a simple list of donors that gave in 2007 and aren’t anonymous. To do this, I need to create a VisualForce page with a simple Apex controller so I can grab the right data, and then display it correctly

Here’s the Apex controller where I’m grabbing the data that I want. You can see from my SOQL statement that I’m only getting Accounts where the rollup field is greater than zero and the anonymous field isn’t checked. I’ve named it donorListing:

public with sharing class donorListing {
	List<Account> accounts;
	public List<Account> getAccounts(){
		accounts = [select name from account WHERE X2007_Giving_Total__c > 0 AND Anonymous_Sponsor__C = false ORDER BY Name];
		return accounts;
	}
}

Here’s the VF Page where I display the data. I point to the Apex I created via the controller attribute of the page. I also turn off the Header, so that I don’t see all the Salesforce navigation elements. Then I just list out the sponsors.

<apex:page controller="donorListing" showHeader="false">
	<apex:dataList value="{!accounts}" var="account" id="theList">
		<apex:outputText value="{!account.name}"/>
	</apex:dataList>
</apex:page>

And here is what the VF page looks like in my browser when I’m logged in to Salesforce.com:

OK, looks great. But I want it visible to people not logged into Salesforce. To do that, I need to create a Salesforce Site.

The Site

You can create a Salesforce site at Setup | Develop | Sites. Create a site, and give it a name. It will show you the URL for this site. That’s the URL people can hit from anywhere on the web to see your VisualForce pages.

You associate VisualForce pages with a Site on the Site detail page. You’ll see here my donorlist page is a part of this site:

Next, I want to make this page visible to the public–I don’t need people to login to see it. That’s done by modifying the public access settings:

Make sure your pages and classes(classes used by VisualForce pages are added automatically) are associated with the site:

OK, now we’re ready to hit the page at it’s external location. For this example, the URL is:

http://smsdev-developer-edition.na6.force.com/sms/donorlisting

The end product

Now that we can see the page publicly, we can embed it anywhere on the web using something called IFRAME. It’s a part of the HTML that runs the web, and has been around for a long time. Here’s the code for embedding this page in my website:

<iframe src="http://smsdev-developer-edition.na6.force.com/sms/donorlisting" width="100%" height="150" frameborder=0>

The nonprofit can now paste that IFRAME code into it’s website content management system. I’ve done just that in this post–you can see the sites page embedded right here:

When you hit this page, you’ll see the live data. If I get new sponsors or I flag sponsors as anonymous, they’ll appear or disappear accordingly. Just manage your data through your normal process and the public acknowledgement just happens.

Heck, you could even put workflow on the Account that automatically sends an email to the Account when they make this list. That email could contain a link to the acknowledgement page. That’s a pretty nice thank you experience for the sponsor, I think.

The challenge

This is a very simple example meant to get you thinking about what’s possible. What do you want to do with Sites? Come up with your own use cases and implement them in a developer org. As you can see, there isn’t much code involved to get it working. Show your boss what’s possible with an example. Tell them how long it took you to get data shared on your organization’s website. Modify the data in Salesforce.com and then hit refresh in the browser. Astound and amaze! And then build Sites into your business process for quick and easy publishing of your Salesforce.com data.

John Kucera is posting an awesome series about doing complex engagement work with Campaigns and the new enhancements in Summer ‘09. This is killer stuff John!

I just posted over on the Salesforce.com Nonprofit blog that we are releasing the Nonprofit Starter Pack as an open source project!

The post tells the full story and provides links to all the relevant resources: project site, issue tracker, code base, and documentation.

Come join us in this effort!

I inherited a code base when I started at the Salesforce.com Foundation. If you’re a Salesforce.com Admin or consultant, you may find yourself in the same position. What’s the best way to come up to speed on a new code base? It can be a daunting process.

In one of my last projects at ONE/Northwest I started working on a very complex Salesforce implementation someone else built. There wasn’t any Apex or VisualForce, but the config was really gnarly. Getting my head around the record types, custom objects, and fields was a real bear. I saw some things I don’t like to talk about…

With my new job, the config isn’t particularly complex. There are relatively few objects and no record types. But there is Apex and some VisualForce. Here are the steps I’m undergoing to get my head around the code:

Put out any fires

• Make sure the code is under source control.
• Deal with any mission critical bugs, but remember you don’t really know what’s going on yet.
• Set up an issue tracker and get it ready to collect issues you discover in this process

Schedule a demo so that you have a short-term goal

• I was asked to demo the NPSP for the Boston user group only a week after I started. I said yes because I knew it would force me to get comfortable with it.
• If you can’t demo to real users, demo to someone who will ask tough questions and understands the business process well enough to make you sweat.
• If you can, build out your own demo org rather than using one that’s already built. You’re code may not be packaged, so this might not work for you.

Understand the application flow

• Read any user documentation you’ve got
• Talk to anyone available who was involved in the design so you can try to understand the intent of the application flow.
• Click through the UI to see what happens
  • Take the time to document the application flow in a flowcharting program, like Visio or Omnigraffle–writing it down forces you to fill in the blanks
• Discover all the button overrides
  • Find out where cool stuff is happening with Triggers and where it’s happening with a VisualForce page

Dig into the code and see how that application flow is accomplished

• Look at existing Workflow to see what processes are handled there
• Look at the code
  • Start with triggers, this is where the action happens
  • Take notes – update the application flow diagram with markers where Triggers fire
  • Look at the existing tests for nods toward key behaviors
• Go back to workflow
  • If your workflow is complex, write detailed tests to prove the functionality
  • Just because you can write Workflow by pointing and clicking doesn’t mean it will be easy to understand the behavior without testing

Document what you now know by heart

• Someone will be inheriting this code from you, so think about what you just went through and be kind.

For me it feel like probing in the dark with little parts of the picture slowly becoming illuminated. Follow your instincts about what to dig into, but don’t go to ground in any one area until you have a shallow understanding of the whole thing. Probe into the darkest corners until there is enough light to know how scary it is, and then move on, shooting for the whole room to reach dusk, and eventually, bright light.

I think it’s fun, this process of discovery. It’s much more fun when the code you are inheriting is well-designed, like this code is. When it’s rationally designed, your life is much easier. You’ll still have lots of work to do, but it won’t feel like a giant tangle of yarn for very long.

I just finished a week down in San Francisco, trying to come up to speed on the Salesforce.com Foundation and what I’ll be doing here. I had four main goals in coming down:

• Meet my new co-workers face to face (the ones in HQ, anyway)
• Get a better read on the culture of the Foundation–that’s hard to do remotely
• Spend time with Steve Wright working through what my main areas of focus should be
• Connect with folks at Salesforce.com the company and learn how best to leverage their knowledge and systems in serving nonprofits

I felt like my trip was a great success in all of those categories. I have great co-workers and it was so nice to spend time with them in meetings, at happy hour, etc. It was really cool to connect with some great people at the Company. The Foundation is a small nonprofit, but we’re connected to this massive software company.

I’ll be at the Foundation filling all sorts of roles that have whole teams at the Company–product management, sales engineering, internal process work, partner support. I’ve already gotten great tips and suggestions from Company employees about how best to get this work done. It’s really exciting.

So I’m feeling good, if overwhelmed. Starting a new job is always a lot to absorb. It’s a bit daunting hearing how the Product Management team gathers requirements, interfaces with developers, and tracks progress, and then realize that I’ll be doing all that by myself! Setting expectations of what we can get done will be key…

It is with a mix of sadness and excitement that I announce my departure from ONE/Northwest to join the Salesforce Foundation. I’ve had a great 4 years building out the CRM consulting program, and the time was right for me to take a very exciting opportunity. I get to work at the source of the force behind the growth of the Salesforce platform in the nonprofit sector.

It’s difficult for me to leave ONE\Northwest. It is hands-down the best environment in which I’ve worked. It’s an incredibly talented team that thrives on respect and shared purpose. It was a tough decision to leave such a great team, and such great friends.

I started at ONE/Northwest in 2005 with the goal of starting a CRM consulting program. The team is now 5 staff, cranking on 10 simultaneous projects. We have a very sophisticated set of consulting practices, some pretty slick code, and a track record of happy customers. I’m very pleased with where we’ve gotten to in the last 4 years. What a ride it’s been!

While I have been the most visible face of the ONE/Northwest CRM team, each member of the team is a strong performer in his/her own right. Most of our best code and practices were suggested and developed by my colleagues, not by me, and I thank them for the great years working together. I’ve learned a lot from these folks, and I’ll miss working with them every day. It has been a real joy.

I’m very excited to join the team at the Salesforce Foundation I’ve come to know over the last 4 years. If you’ve worked with them you know they are great people. I look forward to being able to work toward the mission of getting Salesforce into the hands of nonprofits around the world. That’s a reach I can’t really fathom quite yet.

I am the first overtly technical hire at the Foundation, so I’m sure they’ve got lots for me to do. There are a number of areas where technical expertise will come in handy–the Nonprofit Starter Pack, working with the NPSF community, working with partners who are looking to create nonprofit solutions, partnering with large NGOs who are pushing the platform to new places, and the list goes on. I can’t wait to get started!

To those of you who know me in person or on the web, I don’t suspect you’ll notice too much different. I’m staying in Seattle and I’ll be remaining active in all the fora I currently frequent. I look forward to seeing you there in my new role!

Thanks to everyone at ONE/Northwest who helped make the last 4 years a great experience, and to the folks at the Foundation who have given me this new opportunity! I’ll keep you all posted along the way.

An inside source just told me TEXT(picklist) will be live for formula fields in the next release! See the documentary evidence on the idea exchange. Also included is Workflow Field Updates!

Next up is TEXT(picklist) in Workflow Rules, Approvals, etc.

Awesome work from the declarative team!

I just read Keith Heller’s article about choosing a donor management package over on Idealware. I generally agree with the article–I think his comments on the big picture are applicable. I do have one point of contention, however.

Heller says,

If you consistently hear that the software you want is going to need customization to do what you want it to do, stop and consider what you need—and the limits of the software. Customization is always more time-consuming and expensive than it looks. Ideally, you want something that will work out-of-the-box for your organization. Talk to people who have traveled the customization path and see if it paid off for them and was viable for the long term.

I disagree. In my experience, everyone needs customization.

CRM systems, like donor management, need to support the work you’re getting done in order for them to be helpful. If they don’t support the work, they get in the way of the work. This leads to dissatisfaction, lack of use, and inability to trust the data in the system.

I think that the difference between a usable system, and one that is considered “in the way” can actually be very small. Little usability problems can loom large to users. When the system doesn’t go that last mile, people get frustrated and forget that the system brought them the first 99 miles. All that is forgotten, because some annoying work-around is necessary.

But if the system is customized to fill in that last mile, then it will no longer be seen as a barrier. Often this customization is very small compared to the size of the system as a whole. These are the kinds of customizations people need, and should demand.

While I agree with Heller’s point that all nonprofits are very similar, especially around the way they fundraise, I also know that each nonprofit is, indeed, unique. Each one I’ve worked with has had some business process that was different enough, and important enough to them that we needed to customize the software system to support it. Could they have ditched their practice and adopted some well-defined fundraising strategy supported by a donor management system? Sure. Then they’ve changed their most fundamental revenue-generating business practice at the same time they’re making a software buying decision. I’ve found the groups I work with are reluctant to make that kind of change, and don’t want to tie it to a software purchase.

Customizations can be critical in making a system usable and useful to the organization. I don’t steer organizations away from customizations. I try to help them find the most valuable customizations, and make them as useful as possible.