Salesforce

SalesforceForce.com integrates and optimizes several different data persistence technologies to deliver transparent polyglot persistence for all your applications and devices. With Force.com, you don’t have to deal with the complexity of trying to integrate, manage, test, and support several systems, and you only have to code to a single API, no matter which type of persistence is optimal for a given situation. The following figure is an overview of a sampling of Force.com’s persistence technology.Salesforce存在一个Polyglot Persistence多态存储的概念。应用程序可以通过Polyglot persistence暴露出的统一接口去访问平台上的数据，而无需关心这些数据背后具体的存储技术到底是Transaction Engine, 还是由常驻内存提供，亦或是由支持全文本查找的搜索引擎提供。SAP C4C(Cloud for Customer)作为SAP提供的一款SaaS CRM解决方案，C4C也存在类似Salesforce Polyglot Persistence的设计，我们称之为元数据仓库存储。我们在cloud application studio的package下面能看到许许多多的开发对象：可以想象，这二三十种开发对象后台的存储逻辑和技术都各不相同。每次用户登录Cloud application studio，打开自己工作的package后，都会从后台将自己创建的类型各异的开发对象取出然后显示在studio里。为了给Cloud application studio工具端和其他消费者(比如C4C前端UI)提供一个统一高效的API去C4C后台读取这些模型的数据，C4C设计了一个元数据存储仓库，该仓库提供了一个优化过后的API，相当于设计模式里的Facade(外观模式/门面模式）。该API会根据具体被访问的对象，将请求转发到该对象对应的存储服务提供者(Access service provider)上去。对于API的消费者来说，这些对象具体的存储技术是完全透明的，不需要知道。要获取更多Jerry的原创文章，请关注公众号"汪子熙": ...

从Salesforce官网可以了解到Salesforce的force.com平台里数据库表的设计：https://developer.salesforce….Every logical database object that Force.com exposes is internally managed using metadata. Objects, (tables in traditional relational database parlance), fields, stored procedures, and database triggers are all abstract constructs that exist merely as metadata in Force.com’s Universal Data Dictionary (UDD). 每个force.com暴露出来的逻辑数据库对象在内部都被metadata元数据管理。数据库表，表的字段，存储过程和数据库触发器，在force.com里只不过都是抽象的实体，以元数据的方式存在于force.com的UDD数据字段中。而SAP Netweaver也有类似salesforce force.com的UDD概念，在Netweaver ABAP里成为ABAP Data Dictionary - DDIC，事务码SE11打开。SAP的数据库表有design time和runtime运行时的概念。也支持在ABAP程序运行时动态生成新的数据库表，以及运行时根据数据库表对应的实例，反方向得到其design time信息的方法，类似其他编程语言比如Java中的反射，不过在ABAP里我们不习惯这样叫，而是称之为ABAP Run Time Type Identification, 简称RTTI。以上图显示的数据库表TADIR为例，其字段的元数据都存储在另一张表DD03L里。通过查询条件TABNAME = TADIR, 即可从数据库表DD03L里找到TADIR所有字段的元数据，包括字段名，字段的ABAP data element名称，内部数据类型和字段长度等等。当然大多数时候我们如果需要获取这些元数据，不需要通过查表的方式，ABAP DDIC给我们提供了丰富的API，这些函数的命名有规律：DD*GET:而一张表的运行时信息，通过菜单Utilities->Runtime Object->Display查看：不过这些信息一般来说和ABAP应用开发人员关系不大，所以很少留意。要获取更多Jerry的原创文章，请关注公众号"汪子熙":

Multitenancy is the fundamental technology that clouds use to share IT resources cost-efficiently and securely.多租户支持是所有云服务提供商都需要着力实现的一种技术，用于云基础设施上在成本可控和保证安全性的前提下进行IT资源分享。多租户支持面临的四大挑战：how to keep tenant-specific data secure in a shared database so that one tenant can’t see another tenant’s data?如何保证共享数据库内不同租户间的数据隔离，通俗的说，一个租户不应该看到其他租户的数据。当一个租户对其拥有的schema对象或者应用编程接口进行调整时，不应影响到其他租户的功能和整个系统的可用性。How can one tenant customize various schema objects and an application’s user interface in real time without affecting the functionality or availability of the system for all other tenants?How can the system’s code base be patched or upgraded without breaking tenant-specific schemas?系统基层实现发生变动，比如代码版本升级，或者新的补丁进来时，不应该破坏每个租户私有的对象。And how will the system’s response time scale as tens of thousands of tenants use the service?随着系统租户数量的增加，整个系统的响应时间不应该急剧下降。Force.com’s core technology uses a runtime engine that materializes all application data from metadata—data about the data itself. In Force.com’s well-defined metadata-driven architecture, there is a clear separation of the compiled runtime database engine (kernel), tenant data, and the metadata that describes each application. These distinct boundaries make it possible to independently update the system kernel and tenant-specific applications and schemas, with virtually no risk of one affecting the others.Salesforce应对这些挑战的设计是，采取了一种运行时引擎的思路，所有的应用数据都通过元数据生成，即所谓元数据驱动的架构(metadata driven architecture)。这样一来，模型的元数据作为输入，交给运行时引擎加工，生成运行时使用的模型和数据，三者各司其职，有严格的区分，实现了一种高度动态的内核。注：本文的英文文字和图片来自Salesforce官网：https://developer.salesforce….中文文字为本文作者原创内容。要获取更多Jerry的原创文章，请关注公众号"汪子熙": ...

Salesforce在Jerry的其他文章曾经提到，Salesforce里运行时对象均是通过静态存储的元数据，经过Runtime engine加工而成的。Because metadata is a key ingredient of Force.com applications, the system’s runtime engine must optimize access to metadata; otherwise, frequent metadata access would prevent the service from scaling. 既然元数据在salesforce平台中扮演了如此重要的角色，那么运行时引擎对元数据的高效访问就成为一个重中之重的话题，如果达不到这个目标，频繁的元数据低效访问将无法保证平台上提供服务的高扩展性 high scalability。With this potential bottleneck in mind, Force.com uses massive and sophisticated metadata caches to maintain the most recently used metadata in memory, avoid performance-sapping disk I/O and code recompilations, and improve application response times.Salesforce平台设计了很多复杂的元数据缓存机制，确保最近访问过的元数据驻留在内存里，避免了磁盘IO的开销和代码的重编译，从而确保整个应用的响应时间不会影响元数据访问受到影响。SAPABAP Netweaver也有类似的设计，把很多需要高效访问的数据特别是应用程序的元数据存储到应用服务器的shared memory共享内存里。使用事务码SHMM查看shared memory内容：SAP HANA里还能通过系统视图system view M_METADATA_CACHE_STATISTICS来对元数据的缓存访问进行分析：要获取更多Jerry的原创文章，请关注公众号"汪子熙": ...

我们在创建Sales order销售订单时，需要指定一个RequestedDate：这个字段绑定到了BO字段：CustomerQuote.RequestedFulfillmentPeriod.TimePointPeriod.StartTimePoint.DateTime这是一个0-1的BO内部的association：为什么Requested Date总是比创建日期晚两天呢？是在这里配置的：2 Days意思就是比创建日期晚2天抬头的Requested Date的值会通过C4C BO后台的determination复制给行项目Schedline line的同名字段。要获取更多Jerry的原创文章，请关注公众号"汪子熙":