Salesforce.com certified Force.com Developer Certification Tutorial # 6: Visual Force Pages

This blog post is the sixth tutorial of the Salesforce.com Certified Force.com Developer Certification tutorial series titled ‘Visual Force Pages’. The following is the list of tutorial series.

_____________________________________________________________________________

Exam Outline for Visual Force Pages

User Interface 15%
List and describe the components of any Force.com application user interface (e.g., tabs, applications, detail pages, list views)
Given a scenario, determine the capabilities and constraints of the declarative framework for building a user interface (e.g., what can and can’t be done in a page layout)
Describe use cases for how Force.com pages can extend the user interface in the declarative framework and when to do so
Describe the capabilities and functionality of Force.com sites

VI. Visual Force Pages

1. Introduction to Visualforce Pages

  • 2 types of UI
    • Page Builder
      • UI generated automatically
      • limited/no control of UI behavior
      • limited control over look and feel, but all UIs are consistent
    • Visualforce
      • UI generated by developer/technologist
      • full control of UI behavior
      • full ‘pixel level’ control over UI
  • Visualforce & Apex
    • closely tied
    • PE/GE edition limitations prevent from authoring own apex (app exchange apps is okay)
  • Visualforce inline editor
    • auto-completion
    • full syntax highlighting
    • online doc
    • can be edited through force.com id
  • Developers can include
    • VF tags, Force.com expressions, HTML, Javascript, Flash
    • VF pages are limited to 15 MB
  • view State
    • maintains state across multiple pages or server calls
    • view state inspector
      • shows components contributing to view state
      • must be enabled on user profile
      • is displayed only when using <apex:form>
    • view state limit is 135 kb
  • vf pages
    • understand Salesforce metadata
    • display the same performance as statndard sf pages
    • are automatically upgraded to the next sf release
    • vf conforms to mvc development patter
  • MVC
    • Model – standard or custom object
    • View – pages that are presented to the end user
    • Controller – that determines the logic what happens initates an action such as clicking on a tab, etc.
  • 3 key elements
    • Visualforce pages
      • design definition of an app’s user interface
      • implemented using standard web technologies like HTML & javascript
      • can dynamically detect device and associate them with specific design definitions
    • Visualforce components
      • can be standard or custom UI components
      • over 65 standard sf ui elements available at G
      • referenced via a tag library model
    • Visualforce controllers
      • ability to reuse any standard Salesforce UI behavior like new, edit, save, etc (standard controller) and have access to Salesforce data
      • ability to define new UI behaviors and navigation using apex (custom controller)
  • Visualforce Components
    • pre-built UI constructs which reference standard elements in the Salesforce UI
    • referenced in a VF page using an XML tag
    • dynamic visualforce components
      • are designed in apex
      • allows to create pages that render based on variety of states, such as user’s:
        • permissions, behavior, org preferences, data attributes
      • are not intended to be the primary way to create new vf pages
  • Controllers
    • contain the logic and data references a page uses
    • can be used to maintain state across page interactions
    • are refernced or used by pages, through components that call data or actions
    • each page can reference or use standard controller, custom controller or custom controller extensions
    • each vf page references one main controller
  • types of visualforce components
    • standard controllers
      • are available for all API entities/objects as well as custom objects
      • provide access to standard sf data and behavior
      • are referenced by using <apex:page standardController=”Contact”>
    • custom controllers
      • are coded to create custom behaviors or non standard data sets
      • can be used to create wizards or leverage callouts
      • are invoked by using <apex:page controller=”MyController”>
    • cusom extensions
      • add custom behavior or additional data to standard controllers
      • are invoked by using <apex:page standardController=”Contact” extensions=”MyClass, MyOtherClass”>
  • Expressions and Data Binding
    • uses expression syntax to bind components to sf data and actions in the page’s controllers
    • expressions are linked back to controller data and actions not just to sf in general
    • all content in {!…} evaluated as an expression
    • User.FirstName} shows the current user’s first name in a page
    • data context is provided to controllers by the ID parameter, just as in standard pages.
  • Versioning
    • backward compatible
    • each vf page is saved with version settigns for specified version of api as well specified version of visualforce
  • Visualforce namespace
    • standard tags begin with the word apex
    • custom tags begin with the letter c
    • user can register custom namespaces to be displayed with custom tags instead of the letter c
  • Incorporating VF pages in Salesforce UI by
    • creating links to reference the unique page URL
    • overriding standard buttons to route to the new page
    • overriding tab overview pages to use the new page
    • creating custom tabs for the new page
    • embedding pages into page layouts
    • adding pages to a dashboard
    • using pages as custom help for a custom object

2. Visual Force Tags

  • Tags
    • consists of library of tags
    • can incldue text, html, javascript tags
    • can’t use javascript commenting
  • Tag Rules
    • are hierarchical
    • must be closed in the reversed order they were opened
    • like xml, vf must be well-formed
    • VF and JSP
    • similar to JSP
    • typically begins with <apex>
    • all pages must be enclosed by a set of <apex:page> tags
    • components may contain attributes with values to help further define them
    • vf components are resolved into other code at runtime
  • Tag Bindings
    • Bindings related visual force components with the page controller or other page components
    • 3 types of bindings
      • data bindings – use expression systan to pull the data from dataset made available by the page controller
      • action bindings – uses expression syntax to call action methods for functions coded in page controller
      • component bindings – compnent attribute values to reference other components
  • Tag Data Binding
    • binding goes both ways – read and updated
  • Expression syntax
    • dynamic object data can be inserted using {!objectname.fieldname} syntax
    • global data can be inserted with the added $ syntax, such as
      • User.fieldName}, {!$Page.otherVisualforcePage}, {!$Component.otherVisualforceComponent}
    • local variables can be created to stand in for these expressions as they can become long and unwieldy using the <apex:variable> tag.
  • Action Binding
    • set of actions available through the controller
    • can be called using expression syntax
    • they can be
      • standard actions
      • custom actions
  • Component Ids
    • all vf tags have an optional id attribute
    • this id is used as the DOM id when the page is rendered
    • the tag can be referenced by the id by other tags, javascript, or other web enabled languages
    • the ids should be unique within each page
    • the hierarchy of ids should be specified if the ids are not unique
    • when components (such as tables and lists) support iteration over record collections, the system appends _index to the id for each row, starting with zero.

3. Basic Page Components

  • Layout Components
    • provides a structure to the page
    • provide templates or frames to insert content
    • do not bind directly to sf data
    • are focused on areas where data-bound components can be placed
    • tags
      • apex:page /> – represents a single vf page
      • apex:variable /> – provides a local variable that can be used to replace an expression to reduce long and repetitive text
  • Static  Resource Components
    • a type of sf storage
    • designed for use with vf
    • items required by the vf pages (such as javascript, css, images, etc…)
    • referenced using $Resource global variable
    • recommended method over uploading these files to document tab
    • are uploaded via Your Name|Setup|Develop|Static Resources
    • can be contained in an archive (zip)
    • limited to 5 MB per file and a 250 mb overall
    • use action attr to redirect
    • Components
      • <apex:stylesheet> – to add additional css file
        • are located in /sCSS/directory
        • dStandard.css – most styles for standard objects/tabs
        • allCustom.css – styles for custom objects/tabs
      • <apex:pageBlock>
        • helps build out pages and uses sf stylesheet by default
        • creates an area of a page that is similar to detail page and doesn’t contain the default content
      • <pageBlockButtons> – set of buttons that are styled like standard sf buttons (buttons still need to be created manually)
      • <pageBlockSection> – must be used within a pageBlock component. This tag creates a section with one or more columns
      • <pageBlockSectionItem>
        • used within pageBlockSection component
        • allows to modify data presentation, display the data using a different widget, or present items not based directly on SF object fields
        • if we need to bundle more than one item in the cell, then use outputpanel
      • <apex:sectionHeader> – creates the standard colored header bar displayed under the tabs in the SF UI
      • <apex:toolbar>
      • <apex:toolbarGroup>
      • <apex:tabPanel>
      • <apex:tab>
      • <apex:panelBar>
      • <apex:panelBarItem>
      • <apex:panelGrid>
      • <apex:panelGroup>
  • Coarse Metadata Components
    • provide a large amount of generated code to create familiary Salesforce structures
    • do not allow for much customization to the generated areas
    • Components
      • <apex:detail />
      • <apex:relatedList />
      • <apex:listViews />
      • <apex:enhancedList />
      • <apex:repeat />
    • Chatter tags
      • enable to add chatter into vf paes
      • incorporate chatter into vf pages using
        • the showChatter attribute of <apex:detail> tag
        • <chatter:feed> to include chatter feed on a record
        • <chatter:followers> to include chatter followers on a record
        • <chatter:feedWithFollowers> to include chatter feed, followers and show/hide chatter button
        • <chatter:follow> to add a button that enables you to follow records
    • Message components
      • <apex:pageMessages> – use the standard sf style
      • <apex:messages> – unformatted but can apply custom style
      • <message> and <pagemessage> – specific to one component
      • messages always shows up in system log.

4. Form and Output Components

  • allow entering info into your pages, & uploading files
  • form components
    • <apex:form>
      • enables a section of a vf page to allow users to enter data and subit it with commandButton or commandLink
    • <apex:inputField>
      • corresponds to a SF object field that respects the attributes of that field and uses associated sf UI widget
    • <apex:inputWidget>
      • set of widgets for data that doesnt correspond to a SF object field to be used with pageBlockSectionItem tags
        • <apex:inputCheckBox>, <apex:inputHidden>, <apex:inputSecret>, <apex:inputText>, <apex:inputTextarea>
      • limitations
        • no protection from malicious javascript
        • no escaping/unescaping the data correctly when displayed on a regular page layout
        • no built-in handling of the truncated display of long text fields
        • no special search indexing to ignore tags and focus on the plain text
        • no special handling of the field when used in filters, workflow rules, etc.
    • <apex:selectWidget>
      • series of additional tags to support the display of UI widgets in organized tables
        • <apex:selectCheckboxes>
        • <apex:selectList>
        • <apex:selectRadio>
    • <apex:inputFile>
      • allows users to upload files and turn them into attachments on records, documents  or apex blobs
    • <apex:commandButton> & <apex:commandLink>
      • used within a form tag.
  • output components
    • display info without allowing the user to change any data
    • have parallel form components
    • components
      • <apex:outputLabel> – creates a label for input or output widgets that do not automatically come with a label
      • <apex:outputField> – creates a read-only display of a label and value for a SF field, automatically formatted according to the field type
      • <apex:outputLink> – creates a link to URL
      • <apex:param> – used as achaild tag that provides a name/value pair parameter for its parent compoentn. It can be used with
        • outputLink: defines http query string parameters
        • outputText: defines text insertion parameters
        • actionFunction: defines javascript function parameters
      • <apex:outputPanel> – tag defines a set of content that is grouped together (often for ajax)
        • layout attribute: block, inline, none
          • block: Generates an HTML div tag (adds a paragraph)
          • inline: Generates an HTML span tag (default:doesn’t do any formatting)
      • <apex:outputText> – displays text which can be formatted using a stylesheet
      • <apex:pageBlockTable> – creates a table by iterating over a set of data using the SF stylesheet. good if data comes from sf object. used within pageBlock or pageBlockSection
      • <apex:dataList> – creates a list (a one-column table) by iterating over a set of data
      • [Note: dataList and dataTable are very similar and generally used when you don’t want the standard sf table style. DataLists are just one-column tables.
      • <apex:dataTable> – creates an HTML table which iterates over a set of data
      • <apex:column> – used within either pageBlockTable or dataTable set of tags. it creates the columns for a table
      • <apex:flash> used to embed flash widgets into a vf page
      • <apex:facet> used with a variety of other component tags to provide or override headers, footers, and captions to other items

5. Visual Force Components for Modularity

  • Custom components can stand alone or be accompanied by a custom controller (can be shared in appexchange)
  • <apex:component> – used to create our own custom reusable components
    • access then using <c:componentname>
  • <apex:attribute> – use it within component tag to define the custom attributes, can define the name, data type, and other aspects of the custom attribute
  • <apex:componentBody> – used within a component tag to pull the body of the component’s implementation into the component definition, often used for custom iteration component
  • Page Inclusions (mashups)
    • <iframe> to include another page as URL
    • <incldue> – to include another vf page
  • Template Tags
    • series of tags that are used to create vf template pages and define reusable components for baseline pages
    • tags
      • <apex:define>
      • <apex:insert>
      • <apex:compositions>
  • <messaging:emailTemplate>
    • facilitate communication outside of the application
    • used to create vf email templates
    • must be wrapped inside a single emailTemplate component
    • have advantages over  traditional email templates
    • can be edited using Email Templates (under admin)
  • Messaging tags
    • <messaging:emailHeader>
    • <messaging:htmlEmailBody>
    • <messaging:plainTextEmailBody>
    • <messaging:attachment>
  • With email templates, you can
    • repeat tag to iterate through all of the related records
    • generate pages inside of the template
    • specify a custom email header
    • create attachment using plain text, HTML or VF
  • Visualforce Performance Troubleshooting
    • reduce view state size using only one <apex:form> tag on a page
    • cache frequently accessed resources
    • reduce page size < 15 mb
    • increase the time interval for calling apex from visualforce page
      remove unnecessary fields to reduce the amount of data returned

6. Javascript in Visualforce

  • Action Binding and Javascript
    • currently only actions that are shared across al objects are exposed through standard controllers
    • but further standard sf actions are available by using javascript and the expression syntax with the !URLFOR and $Action keywords
  • Ajax tags
    • 5 tags
      • actionStatus – used to display start and stop statuses of ajax requests
      • actionSupport – used to call 2nd component when an event happens to the 1st component
      • actionPoller – similar to actionSupport, but the event is based on timer instead of a user action
      • actionFunction – provides support of invoking a controller action from javascript code using an Ajax request by defining new javascript function
      • actionRegion – used to demarcate which parts of the page the server should reprocess
  • use rerender attribute to do partial updates
  • simple to implement partial page update is
    • isolation the portion of the page by surrounding it with <apex:outputpanel> tags. be sure to give id attribute
    • create the command button or link that will trigger the partial refresh. add the rerender attribute and assign it the value of the id of the outputPanel created earlier
  • if event happening to same component that should action, use the built-in javascript event attributes
  • if event happening to a different component that will take the action, use the actionSupport tag to handle the event
  • With ajax toolkit
    • create an apex class and expose it as a web service
    • call the web service from a visual force page
      • optionally can attach a page to a button, make it inline, etc.

7. Further Topics in Visualforce

  • force.com sites allow to build public unauthenticated sites that can access data from sf apps
  • 4 main use cases
    • build and run new web applications
      • consumer reviews, hotel conceirge services, event registration sites
    • transform business apps into websites
      • recruiting portal
    • extend your salesforce crm apps
      • interactive web to lead forms
      • campaign landing pages
    • run your corporate web site on salesforce service
      • public websites, intranets
  • Salesforce Mobile
    • licensed client app that can be run on blackberry, iPhone, or windows mobile device
    • provides mobile access to data, email, tasks and calendar
    • includes features such as permissions, page layouts, related lists, dashboards, reports and list views
    • allows administrator to mobilize a limited set of standard objects and all custom objects
    • lite edition is free
  • guidelines to develop pages for mobile
    • evaluate if app interface needs to be redesigned for the use on mobile devices
    • keep the real estate open by not displaying the header or sidebar
    • avoid using lookup fields. For the best user experience, use apex to validate data entry
    • create reusable styles in a separate page and use the include component to add these styles
    • use a third party libary such as iUI that provides iPhone like interface
    • refrain from createing styles as a static resource
  • iPhone
    • set page width to 980 pixels
  • Blackberry
    • doesn’t support inline events
    • doesn’t have built-in navigation
    • viewstate for forms is too large for Blackberry
    • use standard html forms in mobile page instead of using form component
  • 3 methods to develop for multiple platforms
    • Separation and redirection
      • build pages separately and point the mobile tab to the bb page
      • top of the page, include the js to redirect the page, if the target is not a bb device
    • Lowest Common Denomiator
      • create pages that include minimal or javascript
      • use these pages on any supported device
    • Conditional Code
      • create pages that evaluate which device being used
      • offer appropriate markup for each device
  • Mobile Javascript Librar
    • some functions of mobile devices not applicable to desktop clients
      • developers can use js functions in vf pages for javascript enabled devices
        • mobileforce.device.sync()
        • mobileforce.device.close()
        • mobileforce.device.syncclose()
        • mobileforce.device.getLocation()
      • html links can be used to sync/close
  • Mobilizing Visualforce Pages
    • Create new mobile ready visualforce tab
    • add the vf tab to mobile configuration
    • test the page using a mobile client simulator
  • Chatter Data Model
    • FeedItem is the fundamental entity for the chatter data model
    • Feed tracking can be enabled for upto 20 fields per object

Salesforce.com certified Force.com Developer Certification Tutorial # 5: Implementing Business Process

This blog post is the fifth tutorial of the Salesforce.com Certified Force.com Developer Certification tutorial series titled ‘Implementing Business Process’. The following is the list of tutorial series.

_____________________________________________________________________________

Exam Outline for Implementing Business Process

Business Logic 23 %
List and describe how to create formulas, validation rules, and workflow rules
Given a scenario, determine which Force.com feature to use to solve a business requirement and/or describe how to apply the solution
List and describe the capabilities of the Force.com approval processes
Given a scenario, select the appropriate features of Force.com approval processes to satisfy business requirements
List and describe the features of the Force.com platform for debugging and monitoring automated business processes
Describe use cases for extending business logic through Force.com code

 V. Implementing Business Process

1. Implenting Business Processes

  • can be used for
    • preserving data quality
    • automatic processes
    • keeping processes from getting ‘stuck’
    • keeping systems in sync
    • auditing
  • Features
    • Formula fields
    • Validation rules
    • Approval process
    • Workflow Rules
    • Outbound Messaging
    • Field History Tracking
    • Setup Audit Trail
  • Functions
    • ischanged – compares with previous value and returns true if it is changed
    • priorvalue – returns the previous value of the field
    • isnew – checks if a formula is running during creation of new record and returns true if it is
    • ispickval – determines if the value of pickuplist is equal to specified string
    • regex – string used to describe the format of the string according to certain syntax rules. It compares a text field to regular expression and returns true, if there is a match
    • vlookup – returns value by looking up a record value in a custom object. It checks against a key and returns value from that key.
    • isnumber – returns true if a text value is number
    • case – checks against a series of values
    • image – inserts an image
    • htmlencode – encodes text stings and merge field values for use in html (e.g. ‘<‘)
    • jsencode – encodes text strings and merge field values for use in javascript (e.g. apostrophe)
    • jsinhtmlencode – encodes text strings and merge field values for use in javascript within html tags
    • urlencode – encodes text strings and merge field values for use in URLs
  • System Logs
    • display logging info, cumulative limits and source code of transaction
    • used for debugging code snippets
    • used to view debug log or execute anonymous code blocks
    • display system resource info
  • Log levels
    • from lowest to highest
    • Error – lowest, produces distinct results and only error messages
    • warn – warn and error
    • info – info, warn and error
    • debug – includes low level and calls to system.debug
    • Fine/Finer – system.debug, dml, soql/sosl, entrance and exit
    • Finest – includes all messages in previous levels and on apex scripts
  • Debug Logs
    • contain info on database changes, automated workflow processes, validation rules
    • request-response xml, apex script errors, and resources used by an apex script
    • records errors and system processes that occur in an org
    • can be retained and managed for specific users
    • 20 logs can be retained for an org, when max is reached, oldest one is overwritten
    • debug log is different system log
    • system log refers to console link at the top of the page
    • underlying logging system is same
    • sysetm log is live console, debug log is persistent store

2. Preserving Data Quality

  • Validation Rules
    • used to verify that the data entered meets the standards before the user saves the record.
    • Can contain formulas or expressions that evaluate the data in one or more fields
    • return true or false
    • are executed for fields that are stored in the object, but not part of the displayed page layout
  • can be used for
    • enforce conditionally required fields
    • enforce required data formats
    • enforce data consistency
    • prevent data loss
  • can be used in conjunction with a roll-up summary field can be used to prevent users from adding or deleting records

3. Automating Business Processes with Workflow

  • Workflow Rules
    • Entry Criteria then Immediate Actions or Time dependent actions
    • Steps
      • Specify the object (both standard & custom objects are ok)
      • Select Evaluation Criteria
        • only when a record is created
        • when it’s created or edited and now meets the cirteria
        • every single time the record is created or updated
      • Define rule criteria
        • filters or formulas
      • Workflow Actions: immediate or later time
        • Tasks – can be assigned to user, role or record owner
        • Email Alerts – can send email to one or more recipients (from address can be current user address or org wide address)
        • Field Updates – can update a field value on a record (including record type/owner)
        • Outbound Messages – can send specific info to designated endpoint in form of API/SOAP message
      • Time-Dependent Workflow
        • triggered depending on elapsed time (evaluated off of any date field in Salesforce)
        • time-dependent actions have a time trigger
        • the action is queued to fire
      • Some considerations
        • cannot use time-dependent workflow when a rule is set for evaluation, every time a record is created or updated
        • when a new workflow rule is created, it does not affect existing records
        • can monitor and remove pending actions by viewing the time-dependent workflow queue
        • if a record that has an action pending against it in the time-based workflow queue is modified so that the record no longer meets the criteria or the timing changes, the action will be updated in the queue
        • if a record no longer meets the time-based workflow rule criteria, the action is removed from queue

4. Automating business processes with Approval Processes

  • automates routing of records for approval
  • contain one or more steps and can be logically split into 6 steps
  • not automatically sent for approval, user has to submit
  • steps
    • process definition
      • it is determined which records should enter the process and what settings should apply to the whole process.
    • initial submission actions
      • developers decide what happens to a record after it is submitted for approval – actions are locking a record, assigning a task, sending an email, updating a field, sending an outbound message
    • step definition
      • developers determine whether all records should enter the step or whether records only meeting the criteria are chosen.
        • if later is chosen, developer defines the criteria for entry to the step. developer also assigns the approver and determine whether the approver can delegate
        • if there are multiple steps, developers can decide what should happen if a record is rejected at a step after the first step: should it go back one step, or should it be considered a final rejection
    • final rejection actions
      • developers define the actions to be taken when a record is rejected
      • actions are: unlock a record, assign a task, send an email, update a field, send an outbound message
    • final approval actions
      • developers define actions to be taken when a record is approved
      • actions are: unlock a record, assign a task, send an email, update a field, send an outbound message
    • recall actions
      • developers define actions to be taken when a record is recalled from the process.
  • Workflow Rule vs Approval Process
    • Workflow rule
      • are triggered upon save
      • consist of one set of criteria and actions
      • can be modified or deleted
    • Approval process
      • triggered only when a user clicks submit for approval
      • consist of multiple steps, have entry criteria, step criteria and step actions; have initial submission actions, rejection and approval actions and actions for each step
      • some attributes can’t be modified, processes must be deactivated before they can be deleted
  • Skipping steps
    • allows developers to skip steps within an approval process based on specific criteria
    • skip step is a step that has criteria defined to determine whether or not approval is required
    • 3 options
      • go to next step
      • approve record
      • reject record
    • considerations
      • Go to next step” option is only available when editing a step that already has an ensuing step (so first create ensuing step)
      • selection the “go to next step” option in a step and subsequently delete all ensuing steps, sf changes the step to automatically reject record, if the step criteria are not met
      • selecting the “go to next step” in the first step when the record does not meet the criteria for any of the steps in the approval process, rejects the record
  • Parallel approval process
    • can send approval upto 25 different users simultaneously
  • Dynamic Approval Process
    • Used to route records for approval based on complex approval matrices
    • Used to route approval requests to users listed in lookup fields on the record requiring approval
    • Steps
      • create a lookup fields on the object beign approved
        • uses lookup relationship
        • if it requires 3 approvers, then create 3 lookup relationships
      • Create a custom object as an approval matrix
      • Populate the approval matrix
      • Create Apex code to fill in the lookup fields from the approval matrix
      • Create or update an approval process to utilize the new lookup fields
  • Automated processes occur in the following order
    • Validation Rules->Assignment rules->Auto-Response rules->Workflow rules->Escalation rules

5. Auditing Processes

  • Setup Audit Trail
    • tracks changes made to the setup of an org
    • lists the date of the change, the name of the user who made the change and a description of the change
    • displays 20 most recent changes
    • tracks changes for 180 days
    • can choose upto 20 fields per object for tracking changes
  • Field History Tracking
    • allows to track the history related lists for cases, contacts, leads, opportunities, solutions, accounts, contracts, and custom objects
    • modification to any standard or custom field, whose history is set to be tracked, results in a new entry in the History related list
    • for most field types, both the old and new values are captured in the History related list; however those values are not tracked for long text area and multi-select picklist type fields
    • tracks changes for upto 20 fields
  • 3 tools
    • debug logs, setup audit trail, field history

Salesforce.com certified Force.com Developer Certification Tutorial # 4: Designing Applications for Multiple Users

This is the fourth tutorial of the Salesforce.com Certified Force.com Developer Certification tutorial series titled ‘Designing for Multiple Users’. The following is the list of tutorial series.

_____________________________________________________________________________

IV: Designing Applications for Multiple Users

1. Design Considerations

  • need to know the users or actors of the app
  • need to identify
    • data that can be accessed by users
    • data restrictions and revoke access from such sensitive data
    • users who should be allowed to customize the app and assign the necessary permissions

2. Managing your user’s experience

  • Types of licenses
    • every user must have a user license
      • defines the fucntionality permitted for the user and determines the profile available to the user
      • can have only type of user license, but may have many feature licenses
    • Two types of license
      • Salesforce
        • full access to CRM, force.com appexchange apps, standard or custom apps
        • full access to CRM, force.com appexchange apps, standard or custom apps
      • Salesforce Platform
        • custom apps, force.com appexchange apps, no access to CRM functionality, can still use accounts, leads, contacts, reports, dashboards and documents
    • can have add-on features, such as apex mobile user, sf crm content user, marketing user
    • can have more than one type of feature license
  • Profiles
    • define user permissions to perform different functions
    • each profile is associated with a license type
    • profile work with sharing models or role hierarchy
  • profiles control permissions, access to data and the UI
    • Permissions
      • define all actions that a user in a profile can perform
    • access to data
      • controlled by field level security settings which allow to define object and field level permissions
    • user interface
      • page layouts, tabs, applications available for each user, record types for each profile determine what the users will see when they login
    • two types of profiles
      • standard
        • can’t be created or deleted and permissions cannot be customized
      • custom
        • create or clone the standard profile and modify the settings
    • types of permissions
      • Administrative
        • can grant some administrative permissions to custom profile
      • General User
        • control the ability that standard user can do like editing tasks
      • Standard Object
        • control read, create, edit and delete action on standard objects
      • Custom Object
        • control read, create, edit and delete actions on custom objects
      • View All Data allows administrators to view all records regardless of all other security settings
      • Modify all Data – allows administratos to modify all records
      • Customize Application permits administrators to administer the application
      • API only user cannot login to sf.com. such users can only use the application through API calls
      • Password Never Expires prevents password expiring
    • Permission Sets
      • collection of settings and permissions
      • represent a concept like job title
      • handle the system requirements that previously existed on the profiles
    • user can have only one profile, but can have multiple permission sets
    • while assigning permissiosn to users, use profile to assign most restrictive settings and assign additional permissions using permission sets
    • an org can have upto 1000 permission sets
    • permission sets can be used assign additional permissions, but not to deny permissions
    • permissions can be revoked by
      • removing permission from permission set
      • changing a user’s profile
      • disabling a permission set
    • use permission sets to grant permissions for
      • applications, objects, fields, tabs, apex classes, service provider, visual force pages
    • permissions that are not available in permission sets must be set through profiles (login hours, ip access, etc)
    • revoking delete permission for a child object in master child relationship will not prevent deleting the child record if parent record is deleted
  • Field-Level Security
    • restricts access to fields
      • list views, reports, force.com, conenct offline, custom links, mail merge, related lists
    • overrides less restrictive page layout settings
    • set at profile level
    • each profile can have different level of access to object
    • doesn’t allow conditional security of records
    • all users can edit any accessible fields
  • Customizing UI and Profiles
    • Record types
      • define the manner in which data is displayed according to business needs
      • determine the page layout and limit the picklist options based on the profile
      • not security tools – do not subclass or partition the data, they work at the UI level and not at the data level
      • users can change the record type of an existing record and it does not affect the values in the record

3. Controlling access to records

  • Record ownership
    • has a owner, sharing based on owner of a record, can be transferred to any user who atleast has read access
    • child records in master detail relationship do not have owner, they inherit from parent record
  • Types of owners
    • users – full access if a user is owner. if read permission revoked, then they can’t see their own record
    • queues – allows multiple ownership, assigned manually or thru assignment rules
  • Record Access
    • read only access, read-write access, full access
  • Ways to obtain record access
    • Full access: owner, above the owner in role hierarchy, contains modify all data permission in profile
    • Read/Write or Read only: owd, role hierarchy, sharing rules, manual sharing, apex sharing, view all data
  • Profiles vs Sharing Models
    • profiles
      • control access to objects and fields
      • whether user can view positions
      • which fields the user can view
    • Sharing models
      • control access to records
      • control the positions to view
  • OWD
    • security settings that define the base line level of access to records that the user doesn’t own
    • only way to restricts access to data in sharing model
    • 3 level of settings
      • public read-write
      • public read only
      • private
    • Determining OWD
      • identify the most restricted user of this object
      • will there be an instance of object that this user is not allowed to view
      • if yes, then owd is private
      • else,
        • will there be an instance of object that this user is not allowed to edit
        • if yes, then owd is public read only
        • else, then owd is public read-write
    • setting owd for child records in master-detail relationship – child inherits  owd from parents
    • child records in lookup will not inherit owd
    • it is possible to change owd any time, but it may have consequences
    • owd can be set for both standard & custom objects
  • Roles
    • control the level of visibility to org data
    • every user associated to role
    • assuming no sharing rules created, users in the same role cannot access each other’s records
  • Role Hierarchy
    • defines data access rights granted to users at higher roles
    • users access to all records they own and their sub-ordinates
  • record access rolls up with role hierarchy with all standard objects
  • with custom objects, a setting named ‘Grant Access using Role Hierarchy’, this can be prevented
  • Public Groups
    • Roles are two dimensional structures. Public groups are way of grouping users together to grant them record access.
    • Groups are good way to extend access across the nodes in hierarchy tree
    • ‘All Internal users’ is a default public group. Public groups can be made up of any combination of users, roles and subordinates and other public groups.
    • Can use public groups in a sharing rule to reduce the number of sharing rules
    • Public groups can also be used for folder access.
  • Sharing rules
    • are created to grant access to records between users when access does not roll up
    • Using sharing rules, read only and read/write access can be granted to users
    • Sharing rules cannot be more restrictive than owd settings.
  • Manual Sharing
    • used to grant access to records on a one-off basis when randon users require record access.
    • Access rights can be granted by the owner of a record, anyone above the owner in the role hierarchy and by the system adminsitrator
    • It is granted at the record level and is not used to grant access at the organization level
  • Apex sharing reasons
    • allow developers to define the reason why a user or group of users have access to record
    • apex sharing reasons exist only for custom objects and they are defined for individual objects.
    • each object can have up to 10 apex sharing reasons
    • sharing rule has to be created manually using new manual sharing rules
    • deleting apex sharing reasons will delete all manual sharing rules associated with it
    • Users with ‘Modify all data’ permission can change sharing using apex sharing reasons
    • apex sharing reasons should be used programatically and not through the application

4. Designing Data Access Security

  • Establishing Data Access
    • When you want to determine data access for a object,
      • consider the OWD default
      • the owner of the records
      • uses who need access
      • rules governing data access
    • When determining access to sensitive data, you need to analyze the access requirements and restrictions for each profile

Salesforce.com certified Force.com Developer Certification Tutorial # 3: Data Management

This blog post is the third tutorial of the Salesforce.com Certified Force.com Developer Certification tutorial series titled ‘Data Management’. The following is the list of tutorial series.

_____________________________________________________________________________

III. Data Management

1. Data Management Overview

  • Id – first 3 chars identify the object – account ,contact, custom obj, …
  • can access id through – URL, Report, Web Services API, Formulas
  • Format of record ids:
    • 15 digit case sensitive
    • a column in report is displayed as 15 digit
  • 18 digit case insensitive
    • web services api always return 18 digit
    • the api always returns 18 digit
    • the report framework doesn’t expose IDs for all objects
  • System fields
    • Created Date, Created By, Last Modified Date, Last Modified By – these fields can be set only during the initial setup
    • only accessible through API and backward compatible with all SOAP based APIs
    • available to all custom objects, but restricted to account, opportunity, contact, lead, case, task and event standard objects
    • for updates, api will accept either the 15 digit or 18 digit

2. Basics of Upsert & External ID

  • Upsert – insert + update
  • External Id
    • user defined cross reference field
    • can be created for any custom field of type text, number or email
    • helps improve report & API SOQL performance
    • each object can have upto 3 external ids
  • if the external id is matched multiple times, an error is reported

3. Data Management Tools

  • Tools to migrate data
    • application importing wizards
    • web service APIs
      • Data Loader, Partner Tools, Custom-built Tools, Open Source Tools
  • import wizards
    • can load upto 50,000 records – accounts, contacts, leads, solutions or custom objects
    • prevent duplication of data contact, leads, custom objects
  • API based tools
    • can load data to any object supported by API
    • can load more than 50,000 records
    • can schedule regular data loads
    • export data for backup
    • delete multiple supported objects at the same time
  • Data Loader
    • can be run from command line
    • support custom relationships for upsert
    • supports importing from and exporting data to a CSV file
    • supports loading from and exporting data to a database through JDBC
    • available for downlaod in Unlimided Edition, Enterprise Edition & Developer Edition, also available as open source but no support
  • Export – uses SOQL to export records from SF to CSV
  • Insert – inserts new records
  • Update – updates existing records and matches records based on the Salesforce id
  • Upsert – insert + update, matches based on either Salesforce id or external id
  • delete – deletes records from, matches based on Salesforce id

4. Managing Data

  • command line
    • can set the config directory
    • data loader runs whatever operation, file or map that is specified in the config file
    • runs the current directory if no config diretory is specified
    • default config file location: c:\program files\salesforce.com\data loader\version\samples\conf
    • if you use process-conf.xml, setting process.name to the name of a process specifies a process to run. Otherwise, the config.properties file is used for parameter settings
    • supports extract, insert, update, upsert, delete
    • offers encryption utility: Run\bin\encrypt.bat
      • Generate a key: key text is generated onscreen from the text provided
      • Encrypt text: (key file can be provided optionally)
      • Verify encrypted text
    • mass transfer tool to upsert mass data – can be used to transfer multiple accounts, leads from one user to another
    • need ‘Transfer record’ and ‘Edit’ permissions
    • to transfer a record that a user doesn’t own, the user needs to have the required user permissions and read sharing acces on the record

Salesforce.com certified Force.com Developer Certification Tutorial # 2: Analytics as Service

This blog post is part of the Salesforce.com certified Force.com Developer Certification tutorial series and this is the second tutorial titled ‘Analytics as Service’. The following is the list of tutorial series.

_____________________________________________________________________________

II. Analytics as a Service:

1. Introduction to Reports

  • Reports can include both standard & custom objects
  • two users with different access levels see different data with the same report
  • objects & fields are available immediately after they get created
  • reports run in real-time data
  • reports are saved in folder, report security is determined by folder where report is stored.
  • System administrator and users with ‘Manage public reports’ permissions can manage the folders
  • Custom Report
    • 3 panes – fields, fitlers & preview
    • 4 types of reports:
      • tabular – simple listing of data
      • summary – sorting and sub totalling
      • matrix – summarizes data in grid (to compare related totals)
      • joined – can contain data from multiple standard or custom report types
    • can customize by adding more columns, but cannot deselect action & name columns
    • the way the type of report to be created can be identified by:
      • Select Data
      • Select Report Type
      • Select Summaries
      • Select Groupings
      • Select Filters
    • scheduled reports run at user’s timezone who scheduled it
    • to run a report, the report must be in a public folder and the user has to have access to it
    • Hide Details – will show only summary rows, Show Details will show all the data
    • report shows only upto 2000 reports, beyond that the user can export to excel
    • Printable view – exports data to excel with the report formatting
    • Export Details – exports raw data to excel (no report format will be retained)

2. Introduction to Dashboards

  • Dashboard – contains components based on report or chart, can use VF pages to present data, shows data as of the last time it refreshed, can be refreshed manually
  • dashboard can have upto 20 components
  • can choose either 2 or 3 columns
  • dashboard components
    • chart – good for comparisons, is based on report data and the field which you summarize the report is the field that you see on the dashboard
    • table – shows the top/bottom n records, can be used to display totals also, can include upto 4 columns
    • guage – shows progress towards goals, display percentage or total
    • metric – shows single number (grand total)
    • visual force page – pulls data from another source
  • can follow individual components through dashboard alerts and snapshots
  • can post component’s snapshot to dashboard feed to chatter or dashboard feed
  • chart types
    • vertical column – summary report with single grouping. variations: vertical col: grouped, stacked, stacked 200%, good for showing dates
    • horizontal bar – good for summary with single grouping. horizontal grouped, stacked, stacked 200%
    • line – specially used to show data over time
    • donut chart – good for multiple groupings with total amount
    • funnel – good for datasets for multiple groupings in ordered sets and want to show the proportions among them
    • pie – multiple groupings and want to show proportion of single value for each groupings against total
    • scatter – illustrate degree of correlation between two axis
    • combination charts – that includes different sets of data
  • dashboard security
    • dashboard folder – controls who sees the folder
    • running user – controls what data is displayed on the dashboard
  • clicking a dashboard component takes users to underlying source report, filtered source report or another url that the dashboard creator specifies
  • can drill down to single record, but user will see that the security model will allow to see
  • report access is determined by folders
  • it is possible to see a dashboard component, but not the underlying report
  • Dashboard filters
    • let users chose which data to chose
    • each filter based on single field, can specify upto 10 filter options
    • enables users to view different subsets of data on the same dashboard
    • each dashboard can have upto 3 filters
    • filters can be created on date, datetime, currency, pickup, lookup and text fields
    • filters cannot be added with visual force components, scontrol conponents
    • cannot use filters for bucket fields, filter components cannot be followed on chatter
    • scheduling or emailing a filtered dashboard will return unfiltered data
  • Dashboard display info as of date
  • can be refreshed daily, weekly, monthly

3. Custom Report Types

  • Standard Report Types
    • created, when an object is created, allows to report relationships between objects are created (similar to inner joins)
    • the report types cannot be modified
  • Custom Report Types (CRT)
  • unique templates for creating reports, created by administrators or users with ‘Manage Custom Report Types’
  • can include standard or custom objects, allows users to select the objects and fields that should be related for reporting purposes
  • Enable the creation of “with or without” reports
  • Three steps to create a report based on CRT:
    • select the primary object
    • select related records from other objects (optional)
    • can chose upto 4 objects, chose “with or without” for each related object (similar to outer join)
    • Add fields related via lookup (optional)
  • traverse multiple objects
  • use lookups to join other objects
  • can go upto 4 levels deep, supports many to many relationships
  • primary object cannot be changed after the CRT is created
  • there is a limit on # of CRTs  (depends on SF edition)
  • counting rows
    • standard reports show all rows from both the objects (positions & job applications)
    • what if you want to see only unique rows so that within a report of both job applications & positions, you could see how many job apps you have or how many positions you have.
    • in this case, need to create a report that uses custom field to  count the # of records
    • two step process
      • create a new formula field
      • run a report that utilizes this new field
  • to create custom summary formula: 3 steps
    • create formula fields to count the number of records for each object
    • create custom summary formula to calculate the ratio between the number of records for each object
    • optional: create a dashboard component that will show the ratio between the two numbers
  • Bucketing – helps qualifying the data (for e.g. Not qualified, Qualified, Highly Qualified – for candidates)
    • create a new formula field to group the information
    • create or update a report that utilizes the new field
    • create or update a dashboard component using the new or updated report

4. Analytic Snapshots

  • provides trending, can be scheduled
  • schedule the report and capture the data in custom object and report on the data in the custom object to view historical data and analyze trends
  • can be created in 3 steps:
    • create source report (tab/summary)
    • create the target object (custom). Fields in target object should have same type as in the source object that included in the source report
    • setup the analytic snapshot
    • select the source report, select the target object, map the fields on the report to the fields on the custom object and schedule the frequency for taking the snapshot

5.Going Beyond Salesforce Reports

  • exception reports are available in a few places, but not everywhere
  • no reporting on multiple related lists (using crt, you can include custom objects that are hierarchically related
  • there is only one layout or UI for the reports
  • Salesforce reports don’t provide trending capabilities beyond analytic snapshots
  • Salesforce reports provide limited analysis of what changed bet two dates
  • can’t include data in sf report from another source
  • RaaS -that uses Salesforce as a source – then reports on the data by running multiple queries
  • BIaaS – copies all data to local repository, then runs queries off of the copy of the data  (data repository is provided as a service)
  • Data Warehousing – similary to BIaaS, but you own the servers

Salesforce.com certified Force.com Developer Certificate Tutorial # 1: Application Essentials

The very first module of the premier training for DEV 401/Salesforce.com Certified Force.com Developer certification is titled ‘Application Essentials’ and this post has the notes from this training module.

The following is the list of tutorial series.

______________________________________________________________________________

I. Application Essentials

1.Building Your Data Model

  • Id is indexed, 15 char case sensitive, 18 char, case insensitive, first 3 chars consist of code that identify type of object
  • Name is indexed, required field, text (need not be unique)/auto number (usually unique), appear as first column by default in list/related views
  • owner can represent group/user, has additional previliges, default owner is creator
  • limit on custom fields depend on Salesforce edition
  • Data types:
    • Numeric – number, currency, percent
    • Calendar – Date, DateTime
    • Limited Option – checkbox, picklist, picklist (multi-select)
    • Formatted Text – Email, Phone, URL
    • Text – Text, Text Area (255), Text Area (Long-32768), Text Area (Rich-32768,images,links, formatted), Encrypted – any amount
    • Calculation – Auto-Number (system generated), Formula, Roll-up summary (created on master object, allows calculations on details)
  • Properties
    • Name – used programmatically
    • Label – used in UI
    • Universally required field – required field for all record types and will always display on the edit page
    • Unique field – cannot contain duplicate values, can be case sensitive/insensitive
    • External Id – record id from another system. Fields of type: Text, Number, Email. Can have upto 3. Will have custom index, increases report & SOQL performance
    • Default Value – can be based on formula
  • Standard picklist fields can be controlling fields, but not dependent fields, max # allowed in controlling field is 300. In addition, if a field represents both a controlling field and dependent field, it cannot contain more than 300 values
  • A custom multi-select picklist cannot be the controlling field for a dependent field
  • Encrypted fields – the value of the encrypted field is visible to users who has ‘View Encrypted Data’ permission. Contact Salesforce to get this access. cannot be unique, an external id or have default value
  • Lookup Relationship
    • links custom or standard, independent ownership, security, each object can have upto max of 25 lookup relationships, made required/optional, for optional,
    • if field is optional, can use one of the following actions when a lookup record is deleted:
      • clear value of this field (default)
      • don’t allow deletion that is part of lookup relationship
      • delete this records also. cascade delete bypasses security & sharing settings, allowing users to delete records they don’t have access to.
  • master-detail relationship
    • tightly coupled
    • parent field is always required
    • automatically deletes the child
    • when parent is deleted, ownership & access to child record determined by parent
    • cannot have sharing rules
    • manual sharing or queues, on detail objects because these rules and queues require the owner field
    • cannot contain a standard object on the detail side of the relationship
    • master-detail can be configured so that child records on the custome objects can be reparented
    • cannot create master-detail relationship to users & lead objects
    • page layout should include a field in the child object for the associated master record
  • Difference between Lookup & Master-Detail Relationship
    • Lookup
      • max 25 objects
      • parent required or optional
      • security & access are independent for objects
      • deleting parent object may delete the child, if the child field is required
      • link objects across multiple layers
      • lookup field on page layout depends on required/optional choice
      • cross-object field updates and roll-up summary fields cannot be done
    • Master-Detail
      • max 2 objects
      • parent field on child required
      • access to parent determines access to children
      • deleting a parent automatically deletes the child
      • deleting a parent automatically deletes the child
      • the # depends on whether the master object is standard or a custom object (linking objects across multiple layers)
      • lookup field on page layouts is required
      • cross-object field updates and roll-up summary fields can be done
  • Special relationships
    • self relationship (lookup) & many to many relationships (master detail relationship)
    • junction object
      • custom object with 2 relationships
      • also referred as intersection object
      • moved to recycle bin when any of the associated master reocrds are deleted, however deleted permenantly and cannot be restored when both associated master records are deleted
  • Lookup Filters
    • to limit the search results for related fields (lookup, master-detail or hierarchical)
    • filters can be required or optional, value must match the criteria, if it is required

2. Building Your User Interface

  • 3 different ways to customize UI: custom apps, custom tabs, custom layouts
  • file size for custom logo is 20 kb, 300 wide by 55 pixels high, add file to documents tab to have it as a header
  • 3 types of custom tabs
    • custom object tabs – display data from any custom object
    • web tabs – display any external web app in UI tab
    • visualforce tabs – display vf page in UI tab
  • Page Layouts
    • defines organization of fields, custom links, field locations, page section customizaions, field properties.

3. Introduction to Business Logic

  • Cross object formula
    • can be created from objects that are linked either by a master-detail or a lookup relationship
    • can contain objects that span across multiple levels of relationships
    • limit: 10 unique relationships per object across all formulas and rules
    • exceptions:
      • cannot reference in rollup summary fields
      • cannot reference merge fields for objects related to activites
      • cannot reference record owner merge fields for any object
      • If a standard and custom field have identical names or labels, the merge field displays the custom field value.
      • If two custom fields have identical names or labels, the merge field may display an unexpected value.
      • If you create a field label called Email and a standard field labeled Email already exists, the merge field may be unable to distinguish between the fields. Adding a character to the custom field name makes it unique. For example, Email2.)
  • Roll-up summary fields
    • read-only formula fields that can display sum, min, max or record count
    • can add for all custom master-detail relationships & some standard master-detail relationships including account opportunity, and opportunityproduct

4. Migrating Configuration Changes

  • Configuration changes are stored as metadata
    • (new sandboxes that are not activated within 30 days & the sandboxes that have been locked for 30 days will be deleted)
  • 3 tools to move metadata: change sets, force.com IDE, force.com migration took (ANT based)
  • like email, you send a changeset to org
  • apex code should meet 75% of covering test cases
  • system detects incompatibilities bet versions
  • ability to work with change sets is controlled by profile permissions
  • change sets cannot be modified once it is created.

Getting Salesforce.com Certified Force.com Developer Certification

I passed the ‘Salesforce.com Certified Force.com Developer’ Certification on Feb 1st, 2013. This certification is based on the Winter 2013 release. I’m sharing my experience here about what to prepare, how to prepare and how to take the exam along with a set of tutorials/guides that covers the exam material. This is by no means a complete list, but I hope this will help people who has the desire to get the developer certification.

Developer Certification Basics

First of all, one need to understand the key point of taking Salesforce Developer track certification. As you might know, there are two certifications available for the development track.

  • The Salesforce.com Certified Force.com Developer
  • The Salesforce.com Certified Force.com Advanced Developer

For the sake of clarity, I’ll just repeat the official description here: The ‘Salesforce.com Certified Force.com Developer’ certification is for those who want to demonstrate their knowledge, skills and abilities in building custom applications and analytics using the declarative capabilities of Force.com platform. What this means is that the ‘Salesforce.com Certified Force.com Developer’ certification merely focuses on declarative capabilities and not the coding capabilities, which is the subject of ‘The Salesforce.com Certified Force.com Advanced Developer’ certification.

What to prepare?

As always, a good start would be the official page of the Salesforce.com Developer Certification. The first thing that you need to do is to go through the study guide. Familiarize yourself on the topics covered in the study guide. There are many resources available from paid to free options. The following table provides you the list of resources that you want to tap to pass the certification:

# Title Format Cost
1 Instructor led course: Building applications with Force.com (DEV 401) Classroom/Virtual $4,000*
2
Premier Training – Online Courses: Application Essentials, Analytics as Service, Data Management, Designing Applications for Multiple Users, Implementing Business Process, Visual Force Pages
Online $???**
3 Force.com Fundamentals eBook Free
4 Force.com Workbook eBook Free
5 DEV 401 Developer Certification Tutorial from Premier Training (wrote by me) Online Free
6 ForcePrepare.com Tutorials Online Free
7 ForcePrepare.com’s Developer Certification Links to Other Sites Online Free
8 Development with Force.com platform: Building Business Applications in the Cloud Book/eBook $30/$18***
9 Force.com Developer Certification Handbook (DEV401) Book/eBook $67/$29***
10 Pluralsight Training Course – Force.com Platform – The Big Picture Online $29/month ****
11 Pluralsight Training Course – Force.com for Developers Online $29/month ****
* – Comes with free voucher for certification
** – The premier training comes with unlimited edition. I guess the premier training can be bought separately as well, but I’m not sure.
*** – $30 for paperback, $18 for Kindle edition
**** – Doesn’t cover all the topics as prescribed in the study guide, but definitely a useful resource, specifically for newbies.
  • If you can get sponsorship from your company, then you can take the instructor led course; if you are on your own, then $4,000 is little high in my opinion.
  • Likewise, if you have access to premier training through your company’s Salesforce subscription, I highly recommend to utilize it. In my opinion, this will be the single biggest resource that will help you in preparing for your certification.
  • If you have neither of them as stated above, then you have to rely on freely available resources as marked by #3,4,5,6,7 and optionally on the paid edition of a book (#8). Either ways, I would highly suggest to go through the free resources as well, even if you attend the classroom/virtual or the premier training.
  • The premier training is little bit out dated; for e.g. in the Reports module, it talks about only 3 types of reports; Tabular, Summary and Matrix and there is no word about ‘Joined’ report. So going through the other free resources such as Force.com Fundamentals book would bridge these gaps.
  • All of the premier training modules has a sub module titled ‘Introduction to Force.com’ which you can listen for just one module and skip for the rest, as it is repeated for all the modules (and thus saving 30 minutes for each module).

How to prepare?

  • It took me around 3 weeks to prepare from start to finish, approximately 2 hours a day
  • I watched the online premier training three times:
    • 1st time – I simply watched to familiarize the concepts
    • 2nd time – I took the notes which is given below (marked by #5 in the above table)
    • 3rd time – to enforce the understanding on what I learned (during the 2nd and 3rd attempt, I skipped doing the exercises)
  • Signing up for training orgs
    • For premier training, you need to sign up for multiple training orgs. When you sign up, you can select the course module, such as ‘Application Essentials’ which will provide you a pre-configured sandbox.
    • For the Force.com fundamentals and Force.com Workbook, signing up a single training org would be suffice.
    • In both the cases, complete the exercises without fail.
  • Go through the guides that I have written (marked by # 5) and the tutorials from forceprepare.com (marked by #6)
  • ForcePrepare.com has some good links to other resources (marked by #7).
  • Although not a must, if possible, read the book ‘Development with Force.com Platform: Building Applications in the Cloud‘ written by Jason Ouellette. This will be very helpful, specifically, when you don’t have means to attend the instructor led course or the premier training.

About the Certification Exam Questions

  • The questions asked in the certification exam are 100% objective.
  • There is no out of syllabus questions. Every single question came from the syllabus as prescribed by the study guide.
  • Questions types are as follows:
    • true/false
    • single choice
    • multiple choice
    • match the following
  • Majority of the questions are of multiple choice and the ‘match the following’ had only one question
  • With multiple choice questions, be very careful in selecting the right choice(s) as the pattern looked like as follows:
    • many questions had more than one correct answer and you need to select the most correct answers: For e.g. if the question asks to select 2 correct answers, you will find that there will be three correct answers out of four choices, but only two of them will be exactly correct and the third one will be either partially correct or correct only for specific conditions
    • some questions are very tricky such that you need to read the question really very careful.
  • Do not worry much about the governor/edition/feature limits. There were only couple of questions on limits such as how many master detail relationships can an object have?
  • Where there is no mention of edition, always assume it is developer edition.
  • Go through the wizards/menus/setup/object creation/field definition screens and familiarize with the options. Some questions might come from them.
  • I highly discourage against going through the dumps as your primary means of study. Not only that most questions are situation based questions, but the answers that I found in the couple of dumps are entirely wrong, which will only misguide you. You can check the dumps after you finish all the study resources as mentioned above, but take it as a grain of salt.

How to take the exam?

  • Have a good night sleep before the day that you take the exam
  • If you feel tensed/nervous, I suggest you to meditate before you take the exam. At least, take few deep breaths and calm your mind just before taking the exam.
  • Drink fluids/water at least 90 minutes before the exam and use restroom before the start of the exam. Once the exam starts, you can still the use restroom, but the clock will keep running.
  • You will have plenty of time – so do not answer the questions hurriedly. I took only 62 minutes (out of 90 minutes) to complete.
  • The exam allows you to mark for review and come back after you answer all the questions (but before submitting it). But I suggest that take enough time to think through the problem and mark your answer and mark it for review only if you really not sure even after careful thinking. I did mark 20 questions for later review, but after completing it I felt I should be correct for the most questions, if not all – so I just submitted it.
  • A good way to identify the answers, specifically where you either don’t know the correct answer or have doubts, is to eliminate the choices which doesn’t fit the category. For e.g. if the question is something like this:
    • Q: Which report type cannot be used for analytic snapshot?
    • A: i. Tabular, ii. Summary, iii. Pivot, iv. Matrix

Many would chose pivot, because there is no such report type in Salesforce. But that is wrong. Read the question carefully – the question is not about valid report types; it’s about which report type can’t be used with analytic snapshot. So the right answer would be iv. Matrix.

  • You will get the result immediately after the submit, both in the screen and via email.

Certification Tutorial from Premier Training

The following links provides you the complete guide on the topics covered in the study guide. I took these notes from the premier training course.

All the best and wish you good luck in getting certified.

Securing IBM WebSphere Cast Iron Appliance while integrating with Salesforce-Part V

Introduction

This article is the fifth and final part of the article series titled ‘Securing IBM Websphere Cast Iron while integrating with Salesforce. In this article, we will uncover the final piece of the puzzle: authenticating the incoming requests using web services.

Authenticating the user requests

Since IBM Websphere Cast Iron server is in DMZ, it is exposed to the public internet which enables to be accessed from any device. We saw couple of techniques to safeguard the access to the server at various levels from firewall to transport layer in the previous articles. At the application level, the IBM Websphere Cast Iron doesn’t provide out of the box security such as ‘Authentication’ or ‘Authorization’. To overcome this limitation, this article proposes a technique – using external web service to authenticate the client requests. ‘Authentication’ provides the ability for the web service host to challenge the client to provide access credentials, typically user name/password, but not limited to, to enable the access to provide integration capabilities. Authentication process generally involves in using the standard authentication mechanisms such as Windows Authentication, Kerberos or Forms based authentication. Covering the details of these authentication mechanisms is out of scope of this article. Hence this article will focus on providing a simple way to authenticate the client requests using standard web services technology.

As previously said, the IBM Websphere Cast Iron server doesn’t provide any type of authentication or authorization capabilities out of the box. So, a simple technique to overcome this limitation would be to implement the authentication and authorization services in an external stack such as J2EE or Microsoft .NET as standard web services and utilize these web services to provide the authentication/authorization capabilities. These web services in turn can implement any type of authentication mechanism from Windows to Kerberos to Forms based; using either user name/password credentials or a security token based credentials or simply oAuth based authentication.

This article will implement a simple web service based on .NET WCF web services technology to provide the authentication service. The Cast Iron orchestration can utilize this web service to authenticate the incoming requests and route the call or perform further integration logic or simple reject the call based on the result from this web service. The following diagram captures this flow:

AuthenticationProcess

Implementation

Cast Iron Orchestration – This Cast Iron orchestration is an example for calling an authentication web service hosted in external system. The code for the Cast Iron orchestration can be downloaded from here.  The following image is extracted from the Websphere Cast Iron Studio that demonstrates the flow of the orchestration.

TestRequestWithExtAuth

Authentication Web Service – The authentication web service is a simple .NET WCF web service that takes the security credentials as an XML dataset and returns the authentication status.

Since the article’s purpose is to demonstrate the technique, this web service doesn’t implement any particular authentication mechanism. But as the reader can observe, it is fairly easy to implement any type of authentication mechanism within this web service. The code for the .NET WCF web service can be downloaded from here.

Summary

This article series exposed the security challenges in integrating Salesforce with on-premise applications in the context of IBM Websphere Cast Iron as the integration platform. It also explored various techniques from firewall rules to transport level authentication to custom validation service to external authentication service to address these challenges. Neither the security challenges nor the solutions are complete, but it gives an idea about the security concerning the cloud to on-premise integration and various solutions to address them. The techniques explained here can be implemented with any integration platform and not limited to IBM Websphere Cast Iron, though the implementation details will differ.

Securing IBM WebSphere Cast Iron Appliance while integrating with Salesforce-Part IV

Introduction

This article series discusses about securing IBM Websphere Cast Iron Appliance when integrating with Salesforce. In the previous articles, we discussed about the security challenges and some of the methods to address those challenges including protecting the enterprise network using Firewall, SSL/Certificate based authentication. In this article, we will see how requests from cross-organization to cross-environment (from Salesforce to on-premise) can be prevented. This method also protects your organization’s web services from being accessed from other enterprises who are co-located along with your organization’s orgs. Implementing this method along with the solutions described in the previous articles is a powerful method that will secure your enterprises web services from almost any type of unauthorized access.

Background

In a typical enterprise, multiple environments are created to promote development to production. The usual model is to have one single environment for DEV, one for QA, one for Staging and another for Production. The number of environments may vary depending on the organization’s needs, but the bottom line is that there will be multiple organizations (Sandboxes) on the Salesforce side and matching environments at on-premise with mapping from Salesforce orgs to these local environments. At on-premise, each of these environments are either physically or logically separated using various technologies such as NAT and firewall rules are implemented to prevent cross environment access such that DEV servers can talk only to other DEV servers, QA servers can talk to other QA servers, etc. The bottom line is that applications from one environment cannot call into the applications/databases/services in another environment. But this type of implementation is not possible with Salesforce, because Salesforce doesn’t have the concept that we just explained above. Further we explained in part-2 about how the requests originates from Salesforce. To recap, Salesforce has a set of IP addresses for each region (such as North America, Asia Pacific, etc…) and the web service callouts made by the Salesforce client applications carry one of this IP address as their source address. Salesforce doesn’t have the concept of different network segments for the web service callouts, hence by default, there is no way for the enterprises to distinguish the requests to identify if it come from sandbox or production org or even from their own orgs. But not all is lost. The solution proposed here will address this problem, by not only, preventing the cross-organization to cross-environment access, but also prevents access from other enterprises orgs.

Solution

The solution to this problem involves some custom coding along with a Salesforce provided feature called ‘Organization Id’. Every Salesforce organization has a unique identifier called ‘Organization Id’. The ‘Organization Id’ can be found under Your Name | Setup | Administration Setup | Company Profile | Company Information.

A2-P4-01-OrganizationId[4]

Figure 1: Getting the Organization Id

The ‘Organization Id’ is unique for each Salesforce org. It is not only unique with your enterprise’s Salesforce orgs, but also unique universally across all orgs of all it’s clients. That means that if your web service client in Salesforce embed this ‘Organization Id’ in the request, then a web service can catch that and can prevent the call from executing if the ‘Organization Id’ is not in their access control list. This is what exactly we are going to do that. Here is a simple flowchart that describes this technique.

OrgValidation-FlowChart[4]

Figure 2: Flow chart that depicts the solution

As shown in the flowchart above, the client (Salesforce) will send the ‘Organization Id’ along with the input payload when it makes a web service callout to the Cast Iron. Apex provides the User API through which the ‘Organization Id’ can be retrieved which suits well for apex code. We get the ‘Organization Id’ from this object and embed it in the HTTP headers. For outbound SOAP messages, the outbound workflow action itself provides the ‘Organization Id’. Cast Iron will retrieve the ‘Organization Id’ from the request and validates against it’s configuration. If the ‘Organization Id’ matches, it continue to process, otherwise, the web service exits immediately, returning an error code. The following sections will provide step by step details along with the necessary code that implements this pattern.

Developing the OrgValidationService Cast Iron Orchestration

Since we want to validate all the incoming requests, it is best to develop the validation as a separate web service, so that all other web services can call this one web service to validate the ‘Organization Id’. We will call this as ‘OrgValidationService’. This web service will be consumed by all other Cast Iron web services that want to validate the organization ids. The following image is extracted from the Cast Iron studio that depicts the flow.

A2-P4-CI-01-OrgValidationService[4]

Figure 3: OrgValidationService

Previously, we saw that the client has to send the ‘Organization Id’ along with the input payload. This can be done with couple of ways. I preferred to embed the ‘Organization Id’ as part of the HTTP headers, because, this is less intrusive. Had we chose to embed this as part of the input request parameters, instead of putting into HTTP headers, then the XML schema for all of these web services need to be updated to include the ‘Organization Id’ parameter. Here is the logic:

  • The web service receives the input parameter and assigns it to input variable named ‘objOrgInfoRequest’. While assigning we filter it for the value ‘Organization Id’. Please note that apart from the HTTP headers, you will also notice another parameter named ‘OrganizationId’, which will be used if web service callout is made by outbound SOAP message. The following screenshot shows how the ‘Organization Id’ is passed through the HTTP headers.

A2-P4-CI-02-OrgInfo-HTTPHeaders-Mapping[4]

Figure 4: Filtering the input headers to get the ‘Organization Id’

  • The valid ‘Organization Id’ for that particular environment is configured in a variable named ‘OrgIdLookup’. This is retrieved and assigned to a variable.
  • The web service checks the ‘Organization Id’ that came as part of the input parameter and checks against this configured value.
  • If it matches, then it assigns the status to ‘true’, otherwise, it assigns the status ‘false’.

The code for this orchestration can be downloaded from here.

Developing the Test Web Service Cast Iron Orchestration

The Test Web Service Cast Iron orchestration will serve as an example of how the regular Cast Iron orchestrations (that will be developed to support your organization’s business requirements) should utilize the OrgValidationService to validate the ‘Organization Id’. The following image is extracted from the Cast Iron studio.

A2-P4-CI-03-TestRequestService[3]

Figure 5: TestRequestService Web Service to be consumed by Apex code.

This orchestration is exposed as a web service which will be consumed by your apex code. It copies the HTTP headers to a local variable and calls the OrgValidationService passing this variable. If the return value from the OrgValidationService is true, then the orchestration proceeds to execute, otherwise, it terminates immediately. The code for this orchestration can be downloaded from here.

Consuming the OrgValidationService in Salesforce

There are couple of ways the Salesforce can be programmed/configured to consume a web service that is hosted elsewhere. The right solution depends on the needs, but they are as follows:

  • Apex code
  • Outbound SOAP message
  • AppExchange App

Consuming the Test Web Service from Salesforce (through Apex code)

With apex code option, the consuming the Test Web Service from Salesforce is done completely by coding in Apex. Developers choose this option when they want to

  • pull data from multiple objects and pass them as input parameters
  • process the data and derive the input parameters for the web service

Here are the steps to consume the test web service from Salesforce using the apex code.

  • Generate the WSDL from the Cast Iron web service and save it to a folder
  • Login into your dev/sandbox org and go to the section ‘Apex Classes’ under Your Name | Setup | App Setup | Develop.
  • Click ‘Generate from WSDL’ and choose the file that you saved from the Cast Iron studio.
  • If you want to rename the default names provided by the import wizard, go ahead and change the file names. I renamed the files as follows:

A2-P4-CI-05-GenerateFromWsdl[4]

Figure 6: Naming the system generated classes in Salesforce

  • Click ‘Generate Apex Code’ button and click ‘Done’.

Now we need to create a wrapper class that utilizes the stub generated by the import wizard. To do this, click ‘New’ under Your Name | Setup | Develop | Apex Classes. Copy the code given below. This code consumes the test web service by utilizing the stub that we just generated.

public class TestRequestServiceClient {
    @future (callout=true)
    public static void Test() {
        Boolean isSuccess = true;
        try {
            TestRequestServiceWsdl.Provide_ServicePort binding = buildService();
            List<TestRequestServiceRequest.TestRequest_element > elementList = new List<TestRequestServiceRequest.TestRequest_element >();
            TestRequestServiceRequest.TestRequest_element element = new TestRequestServiceRequest.TestRequest_element ();
            binding.Provide_Service('1', 'Test');
            isSuccess = true;
        } catch (Exception e) {
            isSuccess = false;
        }
        //return;
    }
    private static TestRequestServiceWsdl.Provide_ServicePort buildService() {
        TestRequestServiceWsdl.Provide_ServicePort updateStatusInstance = new TestRequestServiceWsdl.Provide_ServicePort ();
        updateStatusInstance.endpoint_x         = 'https://yourcastironwebserver:443/TestRequestService';
        updateStatusInstance.inputHttpHeaders_x = new Map<String, String>();
        updateStatusInstance.inputHttpHeaders_x.put('OrganizationId', UserInfo.getOrganizationId());
        updateStatusInstance.inputHttpHeaders_x.put('OrganizationName', UserInfo.getOrganizationName());
        System.debug('\nOrganization Id :' + UserInfo.getOrganizationId());
        updateStatusInstance.timeout_x          = 60000;
        return updateStatusInstance;
    }
}

Click Save.

Consuming the OrgValidationService in Salesforce (outbound SOAP message)

With outbound SOAP message option, the outbound SOAP action sends the ‘Organization Id’ as part of the request payload. This is the reason that we designed our OrgValidationService to accept both HTTP headers and a separate parameter named ‘Organization Id’ to support both scenarios (Apex code and outbound SOAP messages).

Here is the test web service built to be consumed by an outbound SOAP message. The outbound SOAP message definition provides you the WSDL and the following screenshot shows the test web service implmented using this WSDL. The code for this web service can be found here.

A2-P4-CI-04-TestRequestServiceO[3]

Figure 7: ‘TestRequestServiceO’ web service to be consumed by Outbound SOAP message

Now we have completed all the development tasks. Before start testing, you need to perform the following tasks:

  • Deploy all the three Cast Iron orchestrations in your Cast Iron server (preferably in your development environment)
  • In OrgValidationService, configure the ‘OrganizationId’ configuration property to the organization id of the Salesforce org that you are going to test. You can get the organization id from the ‘Company Information’ link under Your Name | Setup | Company Profile‘ as shown in the Figure 1 above. Note that the organization id that is displayed here is 15 digit and you need to use the 18 digit version, as otherwise, your OrgValidationService will fail. [You can get the 18 digit through many ways. One way is to let it run against your cast iron web service and look at the cast iron log and you will find the 18 digit id (set the log level to ‘All’ in your cast iron server).
  • In Salesforce, update the ‘endpoint_x’ variable in the TestRequestServiceWsdl to point to your cast iron server and save it. (I renamed the system generated file to ‘TestRequestServiceWsdl’. If you choose a different name or if you didn’t rename, then the file name will be different in your case.

With this, we are all set to test it. Invoke the developer console from Your Name | Developer Console and execute the following: TestRequestServiceClient.Test(); Now if you open the debug logs, you will see that the call succeeded. If you check your Cast Iron logs, you would see log message titled either ‘Request came from authorized organization’ or ‘Request came from unauthorized organization’ depending on what value you have configured for the ‘Organization Id’ configuration property in the OrgValidationService orchestration.

Summary

This article is the fourth in the five part article series. The first part described the security challenges. The second part explained how the enterprise can use firewall to filter unwanted traffic other than the trusted networks. The third part continued to explain about transport level encryption. The fifth part will now explain about authorizing the trusted users. This scenario is particularly important if you are going to use Cast Iron server to integrate with other systems including other cloud services such as Docusign, Amazon elastic cloud, Windows Azure, etc.

Securing IBM WebSphere Cast Iron Appliance while integrating with Salesforce-Part III

Introduction

IBM Websphere Cast Iron can solve many integration problems without the traditional coding approach. This article series discusses about the security challenges when integrating on-premise applications with Salesforce. The first part of this article series introduced the security challenges and the second part continued with first of a set of solutions to secure the integration assets located at on-premise. In this article, we will discuss about adding security at the transport level.

TLS/SSL Authentication

Any information that goes in the public internet can be intercepted. Therefore, adequate security should be implemented at the transport level to ensure that the data is completely encrypted and unreadable from the prying eyes. The standard method to secure the transmission of data is by using the TLS/SSL authentication. Basically, in TLS/SSL authentication, the data is secured at the transport level by encrypting all the data that goes through the public internet.  The TLS/SSL authentication not only encrypts the data, but also provides the source and the target the ability to prove their identities. This is a great feature, specifically when integrating with the Salesforce. Recall the  security challenges that we discussed in part-I, where it was mentioned that the requests from Salesforce carry the IP addresses and not the Salesforce.com or other related domain names. Also, these IP addresses are shared by every other enterprises whose orgs are co-located in the same set of IP ranges. So, how does exactly the TLS/SSL solves the problem? The answer lies in the following sections.

One-way SSL/Certificate Authentication

In one-way SSL/Certificate authentication method, the provider secure the data transmission by implementing SSL/certificate based authentication. When a client makes a request to the server, the server proves its identity by providing the following information:

  • A digital certificate from the service provider with the provider’s information, such as Company name, address, phone, email, etc.
  • A digital certificate from the public Certification Authority (CA) such Verisgn, DigiCert, etc.
  • A chain of trust certificates if there are any intermediary CA’s.
  • An encrypted public key which the client can use to decrypt the data that the server uses to encrypt the data being transmitted

When the client receives this information, it verifies the provider’s digital certificate and upon successful verification, it establishes the secure communication with the server. With this method, the data is encrypted end-to-end throughout  the session. I have written a complete walkthrough on implementing one-way SSL/Certificate authentication here as part of five part article series on Making authenticated web service callouts from Salesforce to IBM Cast Iron Using SSL/Certificates. This solves the problem of the following questions:

  • Will the data be encrypted? If so, do we need to have the clients prove its identity?
  • What type of authentication do we need to use?

Two-way SSL Authentication

In two-way SSL authentication method, both the client and server proves their identities to have a secure communication. Once the mutual handshake is successful, a secure communication channel is established and the data transmission takes place on this channel where the data exchange is completely encrypted and can be decrypted only by the source and the target systems. A thorough walkthrough on the concept of two-way SSL/Certificate authentication with working example can be read in my previous article as part of the five part article series on Making authenticated web service callouts from Salesforce to IBM Cast Iron Using SSL/Certificates

This solves the following problems that we raised in the first article.

  • Will the data be encrypted? If so, do we need to have the clients prove its identity?
  • What type of authentication do we need to use?
  • What systems can access our Cast Iron server?
  • Who can be allowed to access our Cast Iron server?

The two-way SSL/Certification based authentication also solves another problem that we discussed in part-I, which is how to make sure if the request originated from our own orgs instead of some other enterprise’s org which is co-located with our org. Since, in two-way SSL/Certificate based authentication, both the parties need to prove their identities, if a request comes from somebody whose identity couldn’t be verified (using SSL/Certificates), then the server rejects the call.

Summary

This article discussed about using SSL/Certificate based authentication on securing the data communication between a server and client. In the next article, we will discuss about how to protect cross organization calls, so that even inadvertent mistakes of pointing to incorrect environments will be detected by the server and prevented from execution.

%d bloggers like this: