You might have seen the recent Beta announcement from Embarcadero for the Enterprise Connectors. I’ve been doing some work with a few of them lately, so wanted to give you an overview of my experiences, starting with the Salesforce driver.
If you’re not aware, the Enterprise Conenctors are a whole bunch of FireDAC drivers that allow you to interact with a wide range of backend systems as if they were relational databases. There are more than 80 systems supported, including Salesforce, Xero, QuickBooks, Magento, ServiceNow amongst others. The theory is that given most RAD Studio developers are very comfortable interacting with a database, if you can make something look like a database, it should be easier to use.
Nice theory, but I was keen to see how well it worked. I’ve done a fair bit of development with Salesforce, including using the API, so I figured I’d try that driver out first.
A few things to note:
- The Enterprise Connectors work with 10.2 Tokyo.
- The beta versions of all the drivers are available in GetIt, so you can try them out really easily.
- They are FireDAC drivers, but they work happily with FireDAC in Professional (despite the Enterprise Connectors name)
First up, connecting to salesforce is very easy. You have a bunch of options for how you connect (see the documentation here) but I went with the simple username, password and Security Token option. These are all available as parameters in the FireDAC Connection wizard, as well as properties in the component.
Once you have your TFDConnection component setup, you can drop down TFDQuery components and start writing SQL. They support a surprisingly rich subset of SQL, including the obvious things like Select, Update, Insert and Delete, but also Inner Joins, Aggregate functions, executing Stored Procedures, and more.
In the case of Salesforce, the high-level mapping is a Salesforce Object is represented as a Table, and Records are, well, Records. I was pleasantly surprised to see it supports custom fields and even custom Salesforce objects.
I put together a quick example to see if I could do a Master Detail across two Custom Salesforce objects (Product Definitions and Attribute Definitions, installed by the CloudSense Managed Package) and it really required almost no Salesforce knowledge. The FireDAC settings for the Master Detail were exactly as they would be for any relational backend, nothing specific to Enterprise Connectors or Salesforce.
Updating and Inserting were equally easy. The following statement inserts a new Account into Salesforce:
INSERT INTO CData.Account (Name) VALUES ('Embarcadero')
Here’s the screenshot inside the IDE where I’ve then done a select to see the new record.
And here it is in Salesforce.
The Drivers integrate nicely into the IDE’s Data Explorer, letting you browse Tables, Views and Stored Procedures, and you can drag-and-drop tables from there to your forms to auto-create the necessary FDConnection and FDQuery components.
To be honest, I didn’t find much to dislike. If I had to pick one thing, at design time the drivers tend to refresh too often, but I really am nitpicking on that one, this is a Beta after all. Everything I tried to do worked, and worked easily, exactly how you’d think it would work if it was a database backend.
I was also pleasantly surprised at how much functionality was exposed as Stored Procedures. For example, there is a GetCustomReport stored proc that lets you execute a Salesforce Report and get the results in a dataset. Drop down a TFDStoreProc component, wire up a grid and you’re away. In 20 minutes I’d adapted one of our internal utilities that currently reads from a CSV file exported from a Salesforce report, to go direct to the report instead. It just worked!
I’ve since gone on to play with the Xero driver and a few others. If there’s interest, I’ll write up a post on those as well, but the experience there was much like the Salesforce driver: straight-forward and predictable. If you know how to use the BDE, FireDAC, or similar, you can now talk to Salesforce (or 80+ other backend systems)
RAD Studio has REST Client components that are powerful, but they involve a bunch of time getting familiar with the different backend APIs. I can see that an awful lot of the integration work we’ve done over the last few years could be done with the Enterprise Connectors components in a significantly shorter period of time. As an example, the first thing I tried to do with it was rewrite a utility we developed for one of our customers. When we first wrote it awhile ago it took 2 or 3 days of mucking around with the Salesforce API to get going. I re-implemented it in less than 3 hours, with an improved UI, and about 40 minutes of that time was spent watching the Enterprise Connectors webinar!
For me, if you or your customers work with any of those backend systems, this is a no brainer, especially as it works with Pro. If you’re an ISV, you can really quickly integrate your application with other systems your customers are using. As a consultant you now have another (or 80+ other) strings to your bow. Even just inside Code Partners, I’ve taken more jobs off my “To Automate” list in the last few weeks than I have in the 6 months prior. I really suggest you grab one of the beta drivers in GetIt and try it out.
I had the same experience with the Salesforce driver. It make it almost fun to work with Salesforce, arguably the most unpleasant and frustrating of all the CRMs. There was a bug in the PickListValues view, however. A quick email exchange with CDatda’s support folks cleared matters up quickly. (They sent me a new driver.) There is an easily implemented log file setting that allows creates a comprehensive audit trail to assist their developers in problem solving. Even with this minor problem, definitely an improvement over Salesforce APIs by at least an order of magnitude.
I heartily second your endorsement.
MV