Begun the clone war has.. A SOAP api for cloning Notes and Attachments in Salesforce

My journey with the Salesforce platform

Photo credit: HJ Media Studios / Foter / CC BY-SA

Few days back, one of my customers reported an issue dealing with notes and attachments using SOAP API. The customer creates all accounts in their backend ERP system and then the accounts are synched with Salesforce using integration through SOAP APIs. The OWD for accounts in set to private in Salesforce. Regularly accounts in the backend system as re-organized and when such re-organization happens, there is a need to move attachments and notes from one account to another account within Salesforce.

Of course, SOAP API supports both Attachments and Notes, so the customer tried to use the ‘Update’ action to change the ParentID of attachment/note. However, they received the following error

<message>
     Attempting to update (as part of an upsert) parent field ParentId with new value 001m0000008ZgncAAC, current value is 001m000000PQtncAAC
</message>
<statusCode>
     INVALID_FIELD_FOR_INSERT_UPDATE
</statusCode>

Even though SOAP api supports…

View original post 1,008 more words

Salesforce Development Best Practices

What is “Technical Debt”?

“Work that needs to be done before a particular job can be considered complete or proper.

If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on”.

In other words…

“All the things, big and small, that left undone will eventually come around to bite you in the ass”.

Salesforce Technical Debt Accrues FAST when:

• Too many “System Administrators”.
• Changing the data model and adding business logic is EASY.
• Less institutional knowledge of Salesforce (typically).

Salesforce “Gotchas” are Painful and Salesforce development takes a lot of effort to do right.

• Governor limits can cause pain unexpectedly if not considered early on in the design process.
• Deployment is tricky business.
• Team development is either the Wild West…or Soviet Russia.

Specific Recommendations:

IMPLEMENTATION & ARCHITECTURE:

Create Standards For…

• Coding Style
• Documentation
• Design Patterns
• Naming Conventions

Coding Style:

Apex code should follow a consistent coding style for the following areas.

• Whitespace :

  – Always use spaces for indentation. Do not use tabs.

• Block Indentation / Column Limit

  – Indent new blocks with two spaces.

  – Code within a 100 character column limit.

• SOQL Queries:

  – Break SOQL Queries across multiple lines.

  – Fields named in the SELECT clause appear alone, one per line.

  – List fields in ascending alphabetical order.

  –WHERE predicates appear alone, one per line.

Apex Documentation:

Use block-formatted (/* */) comments to create Apex code documentation headers.

• File Headers
• Method Headers

• Apex File Headers

  File headers should include…

  – Description of purpose.

  – Names / emails of the author, and subsequent editors.

  – Date of creation, and last modification.

  – Related metadata (eg. classes, triggers, objects, VF pages).

  Apex REST classes should…

  – Note the HTTP methods they serve.

  – Note endpoints when using multiple base URIs per method.

  Triggers and Trigger Handler classes should…

  – Note the Actions being caught and processed.

  Use @deprecated when a class is no longer in use.

• Apex Method Headers

  Standard (non-test) method headers should include…

  – One or two sentence description of purpose.

  – @param description of each parameter

  – @return description of the return type, noting likely returned values / outcomes.

  Test method headers require only…

  – Description of the test’s functional logic.

Visualforce Documentation:

Visualforce Pages and Components should be simultaneously documented in two places.

• File Headers
• Metadata “Description” Fields

Visualforce File Headers:

Use HTML (<! — –>) comment blocks.

File headers should include…

– Description of purpose.

– Names / emails of the author, and subsequent editors.

– Date of creation, and last modification.

– Related metadata (e.g. Classes, objects, pages, components).

File headers should respect a 100 column width limit.

Visualforce Metadata Descriptions

Edit via Setup or -meta.xml

Write for a non-technical audience

Summarize File Header documentation, including…

– Short description of purpose.

– Date of creation

– Full name of original author.

– Administrative notes (if known).

Update only if core functionality changes

Non-Code Metadata Documentation:

Add descriptions for ALL non-code metadata!

Description fields typically hold 255 characters

– 1000 for Custom Objects and Fields

Descriptions should include…

– Short description of purpose

– Date of creation

– Full name of creator

– Administrative references

Specific Recommendations:

DESIGN PATTERNS:

Salesforce-Specific Design Patterns

• Triggers
• “Bulkified” Code
• Separation of Concerns

Triggers:

• One trigger per Object
• Guaranteed order of execution (at least for your code!)
• Implement logic in a separate “trigger handler” class.
• Use static variables to prevent trigger recursion
• All logic MUST be “bulkified”.

What is “Bulkified” Code?

• Acts on collections, rather than single objects.
• Designed with governor limits in mind

– SOQL Queries

• NEVER perform queries inside of loops!
• Query using sets, rather than single-value predicates
• Use SOQL for loops when expecting more than 300 records.
  • Use selective queries!
• DML Operations
  • Always perform DML on collections of SObjects.
  • Be aware of “hidden” DML, e.g. Database.ConvertLead ().
  • NEVER perform DML inside of loops!
• Future Calls
  • Max of 50 @future calls per execution context.
  • No callouts from triggers! Business logic often requires use of @future methods.
  • @future methods called from Triggers MUST be designed for bulk!

“Bulk” Design Patterns:

All code should be “bulk” code!

Public static methods should always be “bulkified”

Public instance methods can sometimes be “non-bulkified”.

But they should have a really good reason!

Commit to “bulk-first” design, and it will eventually become second nature.

Separation of Concerns:

What is SOC?

• Class architecture?
• Naming conventions?
• Mumbo Jumbo?

Naming Conventions:

• Apex and Visualforce Names
• Apex and Visualforce Identifiers
• Objects, Fields, and other Metadata

Apex and Visualforce Names:

• Use UpperCamelCase.
• Avoid using underscores
• Use full names, rather than abbreviations (in most cases).
  • If using abbreviations, be consistent!
• Test classes append “Test” to the name of the covered class.

Choosing a Name:

Apex:

• First word(s) should be the API name of the related component.
  • If too long, use a consistent best-approximation
  • Ignore underscores
• Middle word(s) can provide context (optional)
• Last word(s) should indicate “functional type” of the class
  • Reconsider design of classes that don’t fit one functional type

Visualforce:

For Visualforce names, be descriptive but brief

• Controller classes incorporate the Page / Component name

Apex and Visualforce Identifiers:

Variable Names:

SObjects

Type of SObject should be clear by looking at name

Collections

Should always be plural!

Method Names

UseCamelCase …but the first character is always lowercase.

E.g. useCamelCase () .

All should…

Use descriptive words.

Rapid clarity to others is important!

NEVER use single-character variables.

Objects, Fields, and Other Metadata:

Create and follow common rules for…

Use of underscores to separate words in API names.

Capitalization of words in API names

Must API names and labels match?

Specific Recommendations:

PROCESS / GOVERNANCE:

Recommendations:

Agree on specific org-wide standards, patterns, and practices.

Refactor code and data model

Define a regular Quality Control Cycle.

Agree on Standards:

Figure out what they are

Socialize with your team

Seek support from management

Three Things You Can Do TODAY

• Create a one-page Standards Document
• Make sure you’re using one trigger per object
• Commit to two code reviews

GUYS!! Handle with care your client’s org.

Cheers!!

Using Native Mobile Device Features from Visualforce with Phonegap

The Silver Lining

The prospect of learning hybrid mobile development is daunting for most Salesforce developers. There are just so many new things to learn all at once. And so, whilst recently learning Phonegap, Ionic, Angular and responsive-design for a side project I realised that there is a very simple bridging approach that can teach you some of the basics and that might even result in some cool apps. This bridging is achieved by making the native features of a mobile device (GPS, local storage, camera etc.) directly accessible from Visualforce.

It is dead easy. I swear. And will demystify the hybrid development paradigm for you.

Set up Phonegap

Install Phonegap and Set up an empty project

For this post I’m assuming you know that Phonegap is a framework that allows you to build web applications that are then bundled into native containers (and iOS container for Apple devices, and Android Container for…

View original post 697 more words