Showing posts with label integration. Show all posts
Showing posts with label integration. Show all posts

Friday, August 14, 2015

6 Salesforce Target Attributes Every PowerCenter Session Should Set

When using Informatica PowerCenter to perform ETL jobs that process large data volumes (think millions of records), there are at least six attributes that should be set for each session. And even when loading smaller data volumes, these attributes may still be worth setting to improve performance.

1. Max batch size = 10000


The assumption here is that the session will use the Bulk API, which is the fastest way to load data in Salesforce. Period. As of Summer '15, the maximum batch size for a Bulk API job is still 10,000 records. Let's take advantage of this.

2. Set fields to NULL = checked


With data loads, by default it's best to assume that a blank field means that there is no data from the source system to feed this field. In this case, whatever is currently in the field would be considered invalid, to be overwritten with a blank value during the feed.

3. Use SFDC Bulk API = checked


Self-explanatory.

4. Monitor Bulk Job Until All Batches Processed = checked


When chaining tasks inside a worklet or workflow, monitoring the bulk job until all batches are processed helps to ensure that a dependent task will start only after the predecessor task truly completes. Otherwise, not only would you increase the risk of encountering locking errors, you run the risk of the next task running in the context of stale data.

5. Enable field truncation attribute = unchecked


This is equivalent to the Allow field truncation setting in Salesforce Data Loader. Unfortunately still, as of Summer '15, using the Bulk API prevents us from using this automatic truncation option. So you should be aware that truncating values must be done by other means during the transformation, not the load!

6.Enable hard deletes for BULK API = checked


Why not? This significantly improves the performance of mass delete operations, by skipping the Recycle Bin and erasing the record immediately.

Thursday, May 28, 2015

3 Integration Practices Missing from White Paper

I just skimmed through the Integration Patterns and Practices white paper, which seems like a great primer on some time-tested integration approaches. However, two GA features plus a pseudo-integration option seem to be notably absent from the document.


Am I forgetting any other options? Please let me know!

Force.com Canvas


This is a well documented feature for which I'll summarize the key capabilities as of Summer '15:
  • Authentication via signed request or OAuth 2.0
  • Canvas app in Visualforce via apex:canvasApp component
  • Canvas app in the Publisher as a custom action
  • Canvas app in the Chatter feed as feed items
  • Canvas in the Salesforce1 app via the navigation menu

Lightning Connect


Instead of feeding data back and forth with integration jobs or real-time callouts, Lightning Connect offers a speedy alternative for surfacing external data in Salesforce, using the OData protocol. Simple scenario: Data stored in an on-premise database table can be exposed with a few clicks as an object in Salesforce, that looks and feels to end users like any other standard or custom Salesforce object. No code required!

Furthermore, Summer '15 added some really cool features to Lightning Connect, such as a native Salesforce Connector and the ability to access government and health data backed by Socrata Open Data Portal™. But in my opinion Lightning Connect will become absolutely, ridiculously amazing once write capabilities (still in Pilot) become GA, along with support for Process Builder, validation rules and Apex triggers.

HYPERLINK function in a formula field


Why do I even bother mentioning this? I think simply that the cheapest, crudest means of "integrating" two systems should not be overlooked as an option. Time is money, and if an external system supports deep linking or can process redirects to specific records, using a formula field to dynamically present a clickable URL to a user can be a really quick win.

Sunday, May 17, 2015

Exchange Sync [sic] vs. Salesforce for Outlook

There's an intentional mistake in this Summer '15 post's title: The true comparison is between Email Connect and Salesforce for Outlook ("SFO"), not between Exchange Sync and SFO. If you are currently confused by Email Connect vs. Exchange Sync like I used to be, read on.

Basically, there are two key capabilities desired in any Salesforce-Outlook integration:
  • Record synchronization. Contacts, events (i.e., appointments and meetings), and tasks should be synchronized between a user's Salesforce experience and his Outlook experience.
  • Easy access to CRM data. A user working within Outlook should be able to easily look up records in Salesforce and to attach emails to those records.

Email Connect and Salesforce for Outlook take different approaches to implementing those two capabilities.

Email Connect Salesforce for Outlook
Record Sync Exchange Sync, which uses a service account on Exchange Server and simple configuration in Salesforce to enable fast, auto-magic synchronization to and from any app or device that connects to Exchange Server Salesforce for Outlook service, which must be running in the background on a user's local machine. This means that as soon as the machine is shut down or put to sleep, sync stops completely.
CRM Data Access Salesforce App for Outlook, which produces an interactive side panel in Outlook, using the new apps for Office platform. Using the apps for Office platform means that this app can look and feel native, without a user needing to actually download or install an add-in on his local machine. Salesforce Side Panel add-in, which is an add-in that must be installed on a user's local machine and and then enabled in Outlook
Software? No! Yes, Salesforce for Outlook

While the Salesforce App for Outlook is still being developed to meet and then exceed the capabilities of the currently GA Salesforce for Outlook add-in, admins can actually get the best of both worlds by mixing the two solutions. An admin can implement Exchange Sync (Beta) and still use the SFO add-in, with the SFO sync functionality turned off. This possibility is critically important for organizations that are using an older version of Exchange Server that doesn't support apps for Office.

In short, Email Connect is the true alternative to Salesforce for Outlook. And the long-term vision for Email Connect seems to be a no-software solution that not only syncs contacts, events and tasks, but also gives users an interactive side panel for easily working with Salesforce data directly within Outlook.

Incredibly, "no software" implies that all this to be achieved without the user having to install a single piece of software. Boom!

Friday, April 17, 2015

Exchange Sync (Beta) Resources in Spring '15

It's been a bit hard to find all of the official resources on Exchange Sync (Beta), so I've put together a list of the resources below that I've encountered. Please add comments to share any more that you've found.

Monday, June 23, 2014

Faraday::SSLError certificate verify failed


Faraday::SSLError
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

In recent memory, this is easily the most frustrating error I've had to troubleshoot. I needed SSL to work so that I could establish secure communication between Salesforce and my Rails app on Heroku. Unfortunately, neither Heroku's sample Ruby (off Rails) app nor general OmniAuth documentation seemed to give any insight into the error or how to resolve it.

Piecing together bits of knowledge gleaned from Google searches, I eventually arrived at the following solution for Rails development on Windows 8:

  • Download root certificates in PEM format
  • Set an environment variable called CA_FILE, pointing to the downloaded PEM file
  • Create an omniauth.rb initializer file, as suggested by OmniAuth
  • Specify the :client_options hash value for the :salesforce provider, as shown below

I know I'm going to run into this error again in the future, and hopefully this blog post will help me and hopefully others resolve the problem in the most secure and supportable means available.

Wednesday, June 18, 2014

Rails directories for Heroku Connect

Heroku Connect is a new add-on offering that simplifies data synchronization between Heroku apps and Salesforce. At its core, Heroku Connect periodically syncs selected objects and fields between Salesforce and Heroku. While the demo Rails app provided by Heroku gives a solid recommendation for extending ActiveRecord::Base to create an analog for models in the Heroku Connect database, some gaps still existed in terms of how to best set up your Rails app and define your classes.

After some experimentation, I decided on the following setup for my app:

  • Heroku Connect model paths: app/models/heroku_connect/schema_name/table_name.rb
  • HerokuConnectRecord::Base
  • Autoload lib modules and classes

I'll explain the setup in more detail below, but quick question: How would you set up your Rails app directories for Heroku Connect?

Heroku Connect model paths


All models in your Rails app by default go in the app/models/ directory. Rails knows to autoload models stored in the models/ directory, and as a result it seemed to reason that Heroku Connect models should go in the same directory. But a namespace is needed to prevent conflicts between regular Rails models and Heroku Connect models. And moreover, what if you have multiple Heroku Connect databases in play?

My implementation addresses this by first moving Heroku Connect models into its own namespace a la the heroku_connect/ directory. Next, different Heroku Connect databases can be split by the schema name or some other unique identifier for each database.

Examples of Heroku Connect model class paths, assuming the schema name "salesforce"
sObject NameClass NameModel Path
Car__cHerokuConnect::Salesforce::Car__capp/models/heroku_connect/salesforce/car__c.rb
OpportunityLineItemHerokuConnect::Salesforce::OpportunityLineItemapp/models/heroku_connect/salesforce/opportunity_line_item.rb
AssessmentPeriod__cHerokuConnect::Salesforce::AssessmentPeriod__capp/models/heroku_connect/salesforce/assessment_period__c.rb

Note: For custom object models, the double-underscores can be written as-is in the name of the .rb file. To be more technical, use the String.underscore method in irb to derive the expected name of the model's .rb file. For example, JointVenture__c would become "joint_venture__c.rb", and Lazy_Boy__c would become "lazy_boy__c.rb".

HerokuConnectRecord::Base


Heroku recommends extending ActiveRecord::Base to create a base for all Heroku Connect models. I thought that instead of calling my base class SalesforceBase, I would call it HerokuConnectRecord::Base to be mimic the naming convention for ActiveRecord::Base. While there's no direct need for this to get going, I figured I would adopt this convention in case I need to extend other Active__ modules or classes down the road for Heroku Connect.

All that's needed to set up this class is the following code, placed within lib/heroku_connect_record/base.rb:

module HerokuConnectRecord
  class Base < ActiveRecord::Base
    self.abstract_class = true
    establish_connection ENV['DATABASE_URL']
  end
end

All Heroku Connect module classes would then extend this class, as in:

module HerokuConnect
  module Salesforce
    class Car__c < HerokuConnectRecord::Base
      self.table_name = "salesforce.car__c"
    end
  end
end

Autoload lib modules and classes


Finally, to autoload HerokuConnectRecord::Base (and potentially future custom classes for Heroku Connect), I adopted ifyouseewendy's recommendation to add the following line to config/application.rb:

config.autoload_paths += %W(#{config.root}/lib)

Tuesday, June 10, 2014

Auto External ID for Multi-Partner Integrations

Some companies need to integrate with multiple partner systems, each having its own set of unique identifiers. When you only have one or two of these external identifiers to manage, you can get away with setting up system-specific External ID fields. But happens when you trying to integrate with more than two such systems?

To make things worse, sometimes you have legacy ERP systems (e.g., in the higher education industry) that don’t have unique identifiers stored in a single field. Instead they use inferred keys derived from combinations of other fields.

In lieu of implementing a full MDM solution, one option to easily set up and manage these external identifiers can be to create just three components in Salesforce for each object: two fields and a workflow rule.

Auto External ID


The Auto External ID field is a Formula (Text) field that produces the string that represents the expected, globally unique external identifier. For example, the field could be a concatenation of two other values that produces something like “001154-900100203”.



Having this field also enables administrators to easily troubleshoot problems with the External ID value by comparing the expected identifier with the actual identifier.

{!ObjectLabel} External ID


The {!ObjectLabel} External ID field is a simple Text field configured to be a unique external identifier. The intent is that the Auto External ID value will always be stored in this field, so that DML operations via API’s can match on this field.



The {!ObjectLabel} part of this is simply a recommended labeling convention that helps your field look more like an out-of-the-box Salesforce field.

Set {!ObjectLabel} External ID


Finally, the Set {!ObjectLabel} External ID workflow rule should be configured to fire only when the Auto External ID and the actual External ID values do not match. This way, you avoid having a workflow rule that continuously edits a field blindly even when there is no need to update the field.



The workflow rule makes use of a simple field update that just sets the External ID field to the Auto External ID value.



And that’s all there is to this pattern! Now you can quickly create external identifier fields that are consistently derived and simple to troubleshoot.