D
Dion Picco
Guest
Thank you again to all the Europeans who turned out for Part 1 of 2 of my ‘Crack the Seal on Your Salesforce Data’ webcast this morning. It was a tad early in the morning for me here in the US, but I must confess that the croaky, deep, morning baritone is a vast improvement over my normal tenor.
For those who didn’t get to attend or listen to the entire session, the short summary is that we at Progress DataDirect have two fantastic solutions for integrating and accessing your Salesforce data, both of which use industry standards in the form of SQL, ODBC, and JDBC.
The first solution is a driver that makes Salesforce data appear like just another relational database. This driver is extremely lightweight and can be run from anywhere, allowing your favorite BI or reporting tool to connect to Salesforce data in real-time. It is also very embeddable and high performance, perfect for embedding in your own application.
The second solution is similar but operates through a cloud service called DataDirect Cloud. You still have a single driver that you connect to your BI tools or embed in your application. The difference is that this driver connects to the cloud service, which in turn connects to any cloud application, including Salesforce. For ISVs that need to connect with many different SaaS applications, DataDirect Cloud makes integration with disparate data sources very easy.
In both cases, the solution works with the entire Salesforce ecosystem, including Salesforce CRM, Database.com, Force.com, Veeva CRM, and just about any of the other applications tied to Salesforce. Who couldn’t love that! One single driver: connectivity to all of Salesforce.
As promised, I wanted to make sure I answered all the questions that were sent in during the webcast, so here goes:
1. Advantage of API is that you are protected from changes to the underlying database. How static is the underlying database?
The APIs themselves change 4 times a year, even if the database doesn’t change. Many times that can require you to recode, recompile, and redeploy your application. And there is no guarantee that a database change won’t require an API changes as well.
In general, the database itself is not guaranteed to be static, although it generally doesn’t change in a way that requires you to change your SQL, unless you want to access new fields for example.
More importantly, many times people will externalize their SQL statements such that they don’t have to change the application to adjust them, unlike APIs. APIs by their very nature require a lot of management and maintenance, something which the SQL driver approach shields you from.
2. Beside the SQL knowledge I suppose that we also need to know the data model of SalesForce? Isn’t that too much for a non-technical user?
No, JDBC and ODBC both have a rich metadata API so you can programmatically determine the data structure of SalesForce if you’re writing a program, just like you would for an Oracle database. Furthermore, if you’re a non-technical user you’ll probably use the drivers in a third party application like Tableau/Pentaho/etc., which will detect the structure for you using the metadata APIs available through ODBC/JDBC. As long as you know the fields from Salesforce you want to use, it really isn’t that difficult when you leverage your favorite SQL-compatible tools.
3. Does the solution support SQL update functions or is it reporting only?
Our solution supports full CRUD capabilities, not just read-only (reporting). In fact, the breadth and conformance of our SQL support is one of the things that sets of apart from our competition. This ensures broader compatibility and much more tuning control.
4. My company is building applications on top of Force.com. Can we use this solution to access our data in these?
Absolutely. As I said earlier in this blog (your question is what reminded me in fact), the driver can connect to anything Salesforce, including Force.com and Database.com.
Well, that’s all from me for now. Hope to see some of you again in the next session, next week. I’ll get a bit more technical in that session which should be interesting for you developers out there.
Cheers
–Dion
Continue reading...
For those who didn’t get to attend or listen to the entire session, the short summary is that we at Progress DataDirect have two fantastic solutions for integrating and accessing your Salesforce data, both of which use industry standards in the form of SQL, ODBC, and JDBC.
The first solution is a driver that makes Salesforce data appear like just another relational database. This driver is extremely lightweight and can be run from anywhere, allowing your favorite BI or reporting tool to connect to Salesforce data in real-time. It is also very embeddable and high performance, perfect for embedding in your own application.
The second solution is similar but operates through a cloud service called DataDirect Cloud. You still have a single driver that you connect to your BI tools or embed in your application. The difference is that this driver connects to the cloud service, which in turn connects to any cloud application, including Salesforce. For ISVs that need to connect with many different SaaS applications, DataDirect Cloud makes integration with disparate data sources very easy.
In both cases, the solution works with the entire Salesforce ecosystem, including Salesforce CRM, Database.com, Force.com, Veeva CRM, and just about any of the other applications tied to Salesforce. Who couldn’t love that! One single driver: connectivity to all of Salesforce.
As promised, I wanted to make sure I answered all the questions that were sent in during the webcast, so here goes:
1. Advantage of API is that you are protected from changes to the underlying database. How static is the underlying database?
The APIs themselves change 4 times a year, even if the database doesn’t change. Many times that can require you to recode, recompile, and redeploy your application. And there is no guarantee that a database change won’t require an API changes as well.
In general, the database itself is not guaranteed to be static, although it generally doesn’t change in a way that requires you to change your SQL, unless you want to access new fields for example.
More importantly, many times people will externalize their SQL statements such that they don’t have to change the application to adjust them, unlike APIs. APIs by their very nature require a lot of management and maintenance, something which the SQL driver approach shields you from.
2. Beside the SQL knowledge I suppose that we also need to know the data model of SalesForce? Isn’t that too much for a non-technical user?
No, JDBC and ODBC both have a rich metadata API so you can programmatically determine the data structure of SalesForce if you’re writing a program, just like you would for an Oracle database. Furthermore, if you’re a non-technical user you’ll probably use the drivers in a third party application like Tableau/Pentaho/etc., which will detect the structure for you using the metadata APIs available through ODBC/JDBC. As long as you know the fields from Salesforce you want to use, it really isn’t that difficult when you leverage your favorite SQL-compatible tools.
3. Does the solution support SQL update functions or is it reporting only?
Our solution supports full CRUD capabilities, not just read-only (reporting). In fact, the breadth and conformance of our SQL support is one of the things that sets of apart from our competition. This ensures broader compatibility and much more tuning control.
4. My company is building applications on top of Force.com. Can we use this solution to access our data in these?
Absolutely. As I said earlier in this blog (your question is what reminded me in fact), the driver can connect to anything Salesforce, including Force.com and Database.com.
Well, that’s all from me for now. Hope to see some of you again in the next session, next week. I’ll get a bit more technical in that session which should be interesting for you developers out there.
Cheers
–Dion
Continue reading...