Salesforce的SQL API

这两天在弄Salesforce的报表数据到企业内部数据库的集成需求，这还是第一个Salesforce报表数据集成场景，以前做的都是Transaction的数据，用Salesforce的Public API或者Cast Iron的Salesforce Adapter都能实现，最开始我们找到了Salesforce的Analytic API，是Salesforce的报表数据API，试用了下，用的是REST+JSON，但发现JSON数据很丑，不好解析，看来这个Report API还比较初级；然后又试了Cast Iron的Salesforce SQL Adapter，可以通过SQL语句快速获得数据，而且Cast Iron Handle了Salesforce的Limit，直接配置就OK，但发现嵌套了两层以上的SQL就不Work。无奈之下试了下SOAP API，惊喜发现可以随便组合SQL来取数据，Salesforce就像一个数据库一样可以用SQL查询，而且是基于互联网的HTTP，而不是基于内网的JDBC。

再一次赞下Salesforce的强大和灵活，通常的OLTP系统提供HTTP之上的Web Service和API不足为奇，像互联网上Facebook，Twitter，微信和微博，企业内部的ERP&CRM如SAP，Oracle，基于J2EE或者.net的自开发系统，基于SQL都在企业内网也是JDBC,ODBC，很难跨越互联网。

而Saleforce不仅仅OLTP，也是个OLAP，由于是朵云，通过基于HTTP的SQL API，Salesforce也是面向数据向互联网开放的。如果说面向OLTP通过API开放了应用，那面向OLAP通过SQL API开放了数据，也就是DaaS的开放了。

此外我们在研究开源API方案时候，发现WSO2的DSS也有类似可以将数据源快速暴露成Web Service和API，但详细对比下，WSO2的DSS只能通过IT人员来写SQL发布WSDL，还是一个典型的On-Premise模式，并不能像Salesforce这样，可以将这个灵活性全部交给用户，用户可以自定义SQL，完全是个On-Demand的Cloud模式。我们试图分析技术上如何实现，WSO2的DSS这类On-Premise发布的WSDL是紧耦合在数据上，也就是说如果数据变了，如字段增加和减少，WDSL是要IT人员重新发布的，而Salesforce的WSDL是没有任何具体Salesforce的数据（Salesforce上叫Object）字段，和数据本身没有任何耦合，Salesforce上数据结构的任何变化，WSDL都不变。

还记得当年参加Salesforce培训时，培训人员说Salesforce底层所有数据都只在一张表里，当时觉得是无法想象，你想，所有Salesforce所有用户的所有Object都是在一个表里，包括Object的Metadata信息，所有用户的实际数据信息，并不是想传统应用是一个Object对应一两张表，Salesforce的灵活性根本应该是源自于这个设计和架构。