• Follow us on Twitter
  • Join our Facebook Group
  • Join me on Google Plus
  • Add me on Linkedin
  • RSS
Welcome to the Delivered Innovation blog! close

  • Home
  • Cloud Computing
  • Salesforce
  • DI News & Events
  • Force.com Tips

Author Archive for: Topalovich

Create a Custom Web Form Handler With Force.com Sites

0 Comments/ in Force.com Platform Tips / by Michael Topalovich
December 2, 2011

No doubt you’ve run into this also…we needed a form handler that captured data for sObjects other than Cases or Leads (e.g. custom objects), we did not want to redirect visitors to a new page upon form submission, and our functional requirements were more complex than what the standard Salesforce form handlers could support. The standard Salesforce Web-to-Lead and Web-to-Case form handlers were not an option, so we had to create our own custom web form handler. And because we wanted to keep everything on Force.com, we decided to build this solution using VisualForce pages and an Apex controller served by Force.com Sites. We developed an alternative solution and wanted to share it with the community in the event it could help others.

Use case

You want to capture form data directly in Salesforce from either a VisualForce page served Force.com Sites or from an externally hosted page, but the standard Web-to-Lead or Web-to-Case web handlers do not meet your exact requirements. You may also be using custom JavaScript forms that post data using AJAX, and do not want to blindly pass data to a form handler that will not provide a return to indicate success or exceptions.

Ultimately, we wanted to expose our form handler so it could also be accessed by any of our forms on the web (Force.com Sites as well as others such as our WordPress blog, which uses an HTML / PHP-based form to collect data).

So, here’s what we did

To begin, you need to ensure that Force.com Sites is setup correctly if it is not already.  You can find information on creating and maintaining Force.com Sites here or here.  In our case, we created a “utility” Force.com Site so that we could keep the pages separate from our main Force.com Sites web pages.  We also concealed the Force.com Sites utility subdomain in our custom Site.URLRewriter implementation to avoid AJAX cross-domain issues, but that is a discussion for a future post.

You will need to code up a VisualForce Page and an Apex class to serve as a custom controller to capture the form data and cast values to specific fields in the target sObject.  The VisualForce page itself is very simple in its construct…essentially it will serve two purposes:

  1. Perform a specific Action that calls a PageReference method in the custom controller when the page is invoked.
  2. Return a value in a format that the process calling the form handler is expecting.  In our case, our AJAX method is expecting a JSON object with the result of the form submission (success or otherwise).

This is what the VisualForce page for the form handler that we use for www.deliveredinnovation.com looks like:

<apex:page cache="false" controller="formHandlerSample" action="{!processForm}"  showheader="false" contentType="application/jsonrequest" >
 { success: {!success} }
 </apex:page>

The elements of this page to take note of:
  1. The ‘controller’ attribute is the custom Apex class that contains the logic that will process the contents of the web form
  2. The ‘action’ attribute is the PageReference method contained in the Apex class that will process the form data and generate the required return string
  3. Because our AJAX script is looking for a JSON object to be returned, we declared the contentType of ”application/jsonrequest.” You may find that you need to return XML, HTML, or other text, so update this attribute to suit your specific requirements.

The form handler code:

public class formHandlerSample {
public Map<String, String> urlParams;
public String Error {get; set;}
public Lead formLead = new Lead();
   
public formHandlerSample() {
urlParams = ApexPages.currentPage().getParameters();
}
public Boolean Success {
get { 
if(Success == null) { 
Success = false;
}
return Success; 
} 
set;
}
public void processLead(Map<String, String> formFields) {
if(formFields.size() > 0) {
try {
for(String fieldKey : formFields.keySet()){
if(fieldKey != null && fieldKey != 'null'){
if(fieldKey == 'FirstName'){
formLead.FirstName = formFields.get(fieldKey);
}
if(fieldKey == 'LastName'){
formLead.LastName = formFields.get(fieldKey);
}
if(fieldKey == 'Title'){
formLead.Title = formFields.get(fieldKey);
}
if(fieldKey == 'Company'){
formLead.Company = formFields.get(fieldKey);
}
if(fieldKey == 'Phone'){
formLead.Phone = formFields.get(fieldKey);
}
if(fieldKey == 'Email'){
formLead.Email = formFields.get(fieldKey);
}
if(fieldKey == 'Description'){
formLead.Description = formFields.get(fieldKey);
}
}
}
upsert formLead;
Success = true;
}
catch(System.Exception e) {
System.debug('Houston, you have a problem: ' + e);
Success = false;
Error = String.ValueOf(e);
}
}
else {
Success = false;
Error = 'No form fields received';
}
}
public PageReference processForm(){
processLead(urlParams);
return null;
}
}

Questions?  Suggestions?  Leave us a comment or email us directly at Blog [at] DeliveredInnovation.com.


Lessons from the Road Trip to Dreamforce: Estimating Salesforce Projects

0 Comments/ in Salesforce Architecture / by Michael Topalovich
August 18, 2011

There’s nothing like a ~2,500 mile road trip and the myriad hours in the car to reflect on all of the things that get pushed to the back of my mind throughout the controlled chaos that is my reality day in and day out.

One of the interesting takeaways from the trip to this point (now somewhere just outside Denver) was the connection that I made between planning a cross-country road trip to Dreamforce ’11 and planning Salesforce and Force.com projects: My initial plans always seem to be predicated on perfection and an absence of outside influences. After leading hundreds of projects of all sizes throughout my career, I’ve learned to be realistic and rein in this wide-eyed idealism, but it still makes me wonder…why do we tend to be so overly optimistic when planning projects even though we know that there will always be the potential for “unknown unknowns” and other factors beyond our control?

I started pondering this after having my driving momentum grind to a halt when we hit road construction in eastern Nebraska at 1:00 in the morning. First of all, according to my estimates, we shouldn’t have even been driving at 1AM; granted, it took way too long to get our food at the Thai restaurant outside Des Moines, but at the end of the day what I realized was that I blocked out any thoughts of potential delays or unforeseen circumstances when calculating how long it would take to get from our starting point to our destination. In fact, in hindsight, I remember thinking how Google Maps was wayyyy off in its estimated trip duration…and in the end (slow Thai aside), Google Maps was accurate to within 10 minutes.

How could that be? Well, even though Google can’t possibly (at least given today’s technical constraints) take into account every single factor that could influence how long it might take to get somewhere, someone in Mountain View much smarter than myself created a realistic algorithm that took both the known (kids have to pee, cars need gas) and unknown (two cars decide to take up both lanes going the exact same speed of 15 under the speed limit) into account when calculating trip times. Whereas I just took 640 miles and divided by what I thought was a reasonable average speed given my leadfooted tendencies, Google Maps knew that there were many factors to consider, and gave neither an optimistic nor conservative estimate…it found a sweet spot that proved to be remarkably accurate.

Why don’t we think about project planning in the same manner? Why do we, even in a world where Salesforce and the cloud make it possible to complete technology projects in 8 weeks that once took years, still err towards over-optimism in our estimates of project duration? While we don’t necessarily have to take things like weather, potholes, or rubbernecking into account when thinking through a Force.com project, we do have to take into account the variable complexity of dealing with people, processes, and technology. Yet even though I know this through having learned many lessons the hard way in my career, my mind naturally wants to just look a the starting line and the finish line, apply a simple multiplier, and magically arrive at a precise number that will prove correct again and again…just like that isn’t realistic in something as straightforward and discreet as a family road trip to San Francisco, it isn’t realistic in planning Salesforce projects. While our estimating at DI has reached a level of precision that I am very happy with, how do we find that Google Maps-like algorithm that just seems to have a preternatural ability to tell us when we will reach our destination?

Maybe that will be tomorrow’s epiphany as we’re driving through the majestic scenery of southern Utah.

Mike

Salesforce Excel Connector Tool Reference and Lookup Formula Examples

0 Comments/ in Force.com Platform Tips / by Michael Topalovich
March 30, 2011

The Salesforce Excel Connector is a powerful tool for quickly importing data into Salesforce and Force.com objects. You can also use the Excel Connector to mass edit records, which helps with data quality and data management initiatives. Delivered Innovation has utilized Excel Connector many times to facilitate data migrations involving data models with complex lookup relationships, and we have developed some useful Excel formulas to aid in creating reference tables to lookup record IDs in other objects when there is no apparent foreign key or when we need to find things like non-blank values.

We have put together an Excel spreadsheet with a number of use cases and examples with supporting sample data to demonstrate the functionality of commonly used formulas, from simple lookups to complex array formulas.  The use cases include:

  • Return record ID based on first row returned in a search for values in a specified index given search criteria in a specific cell. This works well when you have a unique or 1:1 value that you want to return.
  • Return the row numbers for any records that match the search criteria (specified in either a cell or by giving an explicit string value). Use the row number to then retrieve a value such as the record ID.
  • Return the row numbers for any records with non-blank values in a specified column. Use the row number to then retrieve a value such as the record ID.

One of the things that we found early on is that the VLOOKUP function was difficult to use and was not returning the results we expected, so we standardized on the use of the INDEX function with an inline MATCH function. The array functions that we have outlined required a significant amount of experimentation and testing, but we have found that these yield consistently high quality results in our migrations and data cleanup projects. We welcome your feedback, please let us know how these work for you and if you have any suggestions or improvements.

Download Salesforce Excel Connector Formulas

Force.com Architecture Design Principles

2 Comments/ in Salesforce Architecture / by Michael Topalovich
March 7, 2011

As I was cleaning up some documentation for an onboarding session that I will be conducting for new Force.com developers that have recently joined the Delivered Innovation team, I realized that the Force.com architecture design principles that form the foundation of everything we design and build might be of value to the community, so I am posting them here on the Force Architects blog. These principles have been gathered from lessons learned on customer projects, from other developers and architects that we have had the privilege to work with, and from books and documentation that we have read and learned from. Let us know what you think, or if there are other principles that you follow that we should consider adding to the list.

—

When working with cloud computing platforms such as Force.com, our architecture must assume that design will evolve over time and that we cannot know everything that we need to know up front in order to fully architect the solution. Our design will generally need to evolve during the implementation stages of the application as we learn more and the design is tested against requirements and feedback from both business owners and customers.

We have to create our architecture with this evolution in mind so that it will be able to adapt to requirements that are not fully known at the start of the design process (what we refer to as either “known unknowns” or “unknown unknowns”). As we design for Force.com, we must consider the following questions:

  • What are the foundational parts of the architecture that represent the greatest risk if we get them wrong?
  • What are the parts of the architecture that are most likely to change, and which parts of the design can we delay until later with little impact?
  • What are our key assumptions, and how will we test these assumptions?
  • What conditions will require us to refactor the design?

When getting started with our design, there are a number of key principles that we need to keep in mind to help create an architecture that leverages best practices, improves speed to market, minimizes costs and operational requirements, and promotes reusability and extendability. The key principles are:

  • Abstraction. Split up the design into granular features with as little functional overlap as possible. The primary challenge is to segment functionality at the appropriate layer of the architecture to cut down on coupling and complexity.
  • Distinct Areas of Responsibility. Each component needs to be responsible only for distinct features or functions, or the aggregation of similar functionality.
  • Principle of Least Knowledge. Components should not know about internal details of other components or objects.
  • Limit Repetition. Specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.
  • Only Design What is Necessary. The amount of upfront design should correlate to the risk of getting it wrong. In our agile methodology, if requirements are not clear, or if the design will evolve over time, spending too much time on design upfront may not make sense as the design will be fleshed out throughout subsequent iterations. It is important, though, to make sure that this iterative design is managed within the scope of our overarching architecture principles and that the final design is tightly integrated with the overall solution.

When designing a Force.com solution, the overriding architectural goal is to minimize the complexity by separating the design into different patterns and components. For example, the user interface (UI), business and validation rules, and data model all represent different patterns with various components. Within each area, the components we design should focus on that specific area and should not mix code from other areas.

  • Keep design patterns consistent.  Wherever possible, components should be designed to be consistent for the function that they perform within the given architecture layer. For example, if ExtJS navigation patterns are used to create a wizard function, you should not include another pattern such as a Flex container, which uses a different method for accessing data and initializing business logic, and creates an inconsistent look and feel. However, you may need to use different patterns for tasks in an architecture layer that have a large variation in requirements, such as a requirement that is highly transactional or requires robust reporting functionality.
  • Avoid duplicating application functionality. If you have a component that provides specific functionality, it should be the only one providing that functionality; it should not be duplicated elsewhere. This allows components to be usable by other components and makes it easier to update components if a specific requirement changes. Duplicating functionality within an application makes it difficult to implement changes, creates inconsistencies over time, and eventually creates operations overhead.
  • Establish a coding style and naming convention for development. A best practice is to use common standards for coding style – things such as indentation, line spacing, capitalization, inline documentation, etc. enable consistency and makes it easier when we have multiple team members on a project reviewing code that they did not write.
  • Maintain system quality using test classes for QA automation. Leverage Apex test methods for unit and integration testing and other automated QA techniques during development. Define clear performance and behavior objectives for components, and build test classes and methods concurrently with core Apex code to ensure that design or coding decisions do not impact the overall quality of the application.
  • Take operations into consideration. Determine what metrics and operational data are required to ensure the efficient packaging, deployment, and operations of the solution. Designing components with a clear understanding of their individual operational requirements will significantly ease overall deployment and operation.

 

—

Acknowledgements

  1. Frederick P. Brooks: The Design of Design: Essays from a Computer Scientist
  2. Microsoft Patterns and Practices Team: Microsoft Application Architecture Guide (there was a time when Redmond knew what it was talking about)
  3. Force.com Development Lifecycle Guide

Render VisualForce Components Dynamically Based on Object Level Security

1 Comment/ in Force.com Platform Tips / by Michael Topalovich
February 5, 2011

We recently came across an interesting situation that I’m sure many Force.com developers have faced at one point or another:  While using VisualForce with standard controllers in the context of a single object gives you access to a fair number of useful standard components exposed by the platform, when you venture beyond the single object or require functionality beyond what the platform gives you “out-of-the-box,” the custom code can pile up fast.

The specific use case that we had to address dealt with dynamically exposing components on the VisualForce page based on the object level security of the logged in user’s profile – in this case, it was buttons (apex:commandButton) and links (apex:commandLink). Because we were displaying input fields (apex:inputField) and output fields (apex:outputField) from a number of different custom objects, and because the actions corresponding to these buttons and links were custom PageReference methods that did a lot of data manipulation, we couldn’t simply reference standard actions such as {!save}.  And because not every user had access to the CRUD function associated with a given custom button or link, we wanted to only show them buttons and links that corresponded to an action that they could actually perform, rather than leading the user down a path that would ultimately throw an exception and frustrate them.

We knew we could write a fairly complex set of sObject describe methods that would populate boolean variables which we could then reference in the redered=”xxxx” attribute of the button and link definitions, but there had to be a better solution – we weren’t looking for a shortcut, but we didn’t want to leave the client with a ton of code that would be difficult to maintain and update over time. The solution ended up being elegant and straightforward, and leveraged a VisualForce global variable called $ObjectType that we didn’t realize was as powerful as it turned out to be.

The VisualForce documentation doesn’t do $ObjectType justice:

A global merge field type to use when referencing standard or custom objects such as accounts, cases, or opportunities as well as the value of a field on that object.

What salesforce.com should state in the documentation is that the $ObjectType is essentially a way to perform sObject describes natively in the context of the VisualForce page, without having to write a single line of custom controller or controller extension code.  It’s a pretty powerful function, and the only reason we went down the path of using it as a replacement for complex sObject describe methods is that we came across this page in the VisualForce Developer’s Guide, and thought to ourselves that if we could check object accessibility using $ObjectType.accessible, which looks a lot like the ‘isAccessible‘ sObject describe result method, then we might be able to use the similar nomenclature to check for object editability, deletability, etc.  This turned out to be the case, and we had our solution.

So let’s say you want to have a ‘New’ button on your VisualForce page that corresponded to a custom PageReference method called ‘newRecord’, and you only wanted that button to be visible to users that had ‘Create’ access on the corresponding standard or custom object.  What you want to do is something like this:

<apex:commandButton action="{!newRecord}" value="New" rendered="{!$ObjectType.myCustomObject__c.createable}" />

Using $ObjectType.objectName.createable returns a boolean (true/false) value that tells you whether the logged in user has the ability to create (the ‘C’ in CRUD) new records for the ‘myCustomObject__c’ custom object.  If the user does not have the necessary object level security, the expression will return ‘False’ and the component will not render.  If the user does have Create access, then the button will render because the expression will return ‘True.’

While we did not test this method with every possible sObject describe method, we did use it to create an ‘Action’ column to mimic the standard ‘Edit  |  Del’ pattern that you see on standard Salesforce list views, so we know for sure that you can check the ability to access, create, edit, and delete records for a given object.  The VisualForce code looks something like this:


<apex:pageBlockTable value="{!getSomeRecords}" var="r" cellpadding="8">
<apex:column width="10%" >
<apex:facet name="header"><b>Action</b></apex:facet>
<apex:commandLink action="{!myCustomEditLink}" rendered="{!$ObjectType.myCustomObject__c.updateable}">
<apex:outputText value="Edit"/>
<apex:param name="editId" value="{!r.id}"/>
</apex:commandLink>
<apex:outputText value=" | " rendered="{!$ObjectType.myCustomObject__c.updateable && $ObjectType.myCustomObject__c.deletable}"/>
<apex:commandLink action="{!deploymentDelete}" onclick="return confirm('Are you sure?');" rendered="{!$ObjectType.Deployments__c.deletable}">
<apex:outputText value="Del" />
<apex:param name="deleteId" value="{!r.id}"/>
</apex:commandLink>
</apex:column>

and so on...

As you can see, we were able to dynamically render the ‘Edit’ and ‘Del’ links, as well as the ‘ | ‘ spacing character all based on the CRUD / object level access of the user accessing the VisualForce page.  This saved us a lot of time, and will be fairly straightforward to maintain and update over time.

Here’s a little cheat sheet:

Show a component only if the user has ‘Create‘ access to an object:

<apex:commandButton action=”{!newRecord}” value=”New” rendered=”{!$ObjectType.myCustomObject__c.createable}” />

Show a component only if the user has ‘Edit‘ access to an object:

<apex:commandButton action=”{!editRecord}” value=”Edit” rendered=”{!$ObjectType.myCustomObject__c.updateable}” />

Show a component only if the user has ‘Delete‘ access to an object:

<apex:commandButton action=”{!deleteRecord}” value=”Delete” rendered=”{!$ObjectType.myCustomObject__c.deletable}” />

Note: An alternative solution can be found here.

Force.com Data Modeling – Normalization is Not Your Friend

0 Comments/ in Salesforce Architecture / by Michael Topalovich
December 28, 2010

Force.com makes configuring the data model deceptively simple; creating new custom objects and custom fields can be accomplished with a few clicks and in a matter of seconds.  This simplicity can end up creating stifling complexity, because the tendency of developers new to the platform is to apply traditional relational design techniques to the Force.com data model, which is a mistake.

In a traditional relational database, data can be easily stored and retrieved by traversing the relationships between tables.  In Force.com, the misuse of relationships by applying normalization patterns can significantly increase coding requirements and create major performance issues due to limitations imposed to govern the use of resources in the multitenant environment.

While it may seem counterintuitive, the key to successful Force.com data model design is to understand that a pattern of denormalization, with tightly coupled attributes that describe a core entity, is the most efficient way to expose data to the Controller and Business Logic layers for presentation to the View / UI layer.

The Force.com data model is, for all intents and purposes, “metadata metadata.”  The database is abstracted by a core metadata layer that exposes basic attributes such as field name and field type, but this metadata is intended to enable further abstraction for data layer interfaces and validation logic.  The actual core database tables are provisioned in a manner similar to a “big table” paradigm in that new objects are allocated space for the core attributes to describe the object such as name and ID, along with up to 500 columns that are abstracted by metadata.  To this point, trying to apply relational database normalization patterns is actually detrimental to overall system performance, as each new object that is created consumes significant metadata storage and provides no performance gains.

Page 1 of 10123›»

Salesforce CRM, Force.com, Cloud Computing: Application and System Design

Latest Posts

  • Doing Business in the CloudApril 10, 2012, 12:22 pm
  • Delivered Innovation Co-Hosts ITA “State of the Cloud” EventFebruary 22, 2012, 1:30 pm
  • Force Feed 2-20-2012February 20, 2012, 1:21 pm
  • Cloudup 2-17-2012February 17, 2012, 9:45 am
  • State of the Cloud Event RecapFebruary 16, 2012, 4:37 pm

Topics

  • Cloud Architecture (173)
  • Delivered Innovation News & Events (30)
  • Force.com Platform Tips (6)
  • Salesforce Architecture (32)

Follow us on Twitter

Follow @twitter

Latest Tweets

  • Up 38% from a year ago, http://t.co/JEY1hGq5 continues to grow. http://t.co/e7q7MztA
    May 17, 2012 - 3:24 PM
  • RT @Benioff: Congrats salesforce on an amazing quarter. The fastest growing software company of our size! 38%! $3B guide! http://t.co/L ...
    May 17, 2012 - 3:05 PM
  • We have a couple new Apps coming; look forward to giving you a peek soon.
    May 17, 2012 - 12:44 PM
  • Cloud is a corporate strategy, not a tactical solution http://t.co/QltTfDFz
    May 10, 2012 - 7:45 AM
  • Chicago #cloudforce - how fast the day goes... http://t.co/YjRI1vp3
    May 4, 2012 - 9:47 AM

Force.com VAR: Value Added Reseller Partner

Salesforce.com Consultant: Registered Consulting Partner

Salesforce.com ISV: Independent Software Vendor Partner

Tags

#df11 Amazon Apex AppExchange Appirio Chatter cloud Cloud Computing Cloudforce cloud security Coghead Delivered Innovation News Dreamforce ExtJS facebook Force.com Gartner Google heroku IaaS IBM Interop ITA IT service delivery Jonathan Sapir Marc Benioff Michael Topalovich Microsoft Oracle PaaS Platform as a Service public cloud SaaS Salesforce Salesforce.com Sencha SOA Social Media Software as a Service Spring '12 the cloud twitter VisualForce Vmware Winter '12

Salesforce CRM, Force.com, Cloud Computing: Application and System Design


View Larger Map

Delivered Innovation
688 N. Milwaukee Ave #202
Chicago, IL 60642
888.645.2604

Delivered Innovation

  • Delivered Innovation Home
  • DI on AppExchange
  • DI on Facebook
  • DI on Google+
  • DI on LinkedIn
  • DI on Tumblr
  • DI on Twitter
© Copyright - Delivered Innovation Blog - Wordpress Theme by Kriesi.at