不推荐的作法：数据库里把ID设为Number类型，Java里设为字符串类型
ID一般是自增的，所以数据库里应设为Number类型 Java里可以把它置为String类型，因为ID纯粹是一个标识，并没有数字意义（不参与加减乘除） 然而这里有个小陷阱：类型转换时会出问题。 数字格式化为String时可能会产生逗号，带逗号的String未必能舒服地转回成数字。 当你的系统与另外一个系统交互，且另外一个系统要求ID为数字类型时，这种问题就可能成为灾难。
Month: March 2011
SalesForce: 调用自定义API时应如何处理session问题
你用APEX写了一个API (Web Service), 然后用wsc生成stub，然后用其中的connector生成soapConnection，最后调用你的API。结果你遇到这样的错误： “INVALID_SESSION_ID: Invalid Session ID found in SessionHeader: Illegal Session” 这是因为connection生成soapConnection时并不会去登录，也就不会生成session id. 解决办法是先生成Enterprise Connection，把这个Connection里的session-id取出来，再塞到自定义API对应的soapConnection中。
如何实现Web Service的Idempotency
摘自《SOA In Practice》 一个Service执行一次请求产生的结果，如果跟执行多次同样的请求产生的结果相同，则可以说这个Service满足了Idempotency 1. Reading Service都是Idempotent 2. "update bonus = 100 where id = 3" 是Idempotent 3. "update bonus += 100 where id =3 " 不是Idempotent — 操作结果依赖数据原先状态的Service都不是Idempotent 为了把这种Service变成 Idempotent,应该遵守这样一种契约：Consumer的请求里应该有一个RequestId, 重发时仍然使用同样的RequestId; Provider收到请求后要将RequestId存起来，如果新请求的RequestId已经存在了，就不要再执行相应的操作。
松散的系统交互方式: One-way Messaging, Compensation 和 Idempotency
为了让两个交互的系统能够减少耦合，它们之间的消息交换方式应该尽量松散。 为了使交互变得松散，可以采用以下手段或者遵循以下准则： 1. One-Way Messaging. 即异步调用。一个典型的例子就是request/callback: 给对方系统发一个Notification，让对方在它方便地时候回调我们，拿它想要的东西 2. Compensation. 为了保证事务的原子性，一般可以采取“两阶段提交”手段； 但这种手段要求两个系统都要使用相应的基础设施，比较麻烦； 替代方案是在发生单边数据时采用Compensation操作： 要么系统自动把本方已生成的数据取消，要么发一封邮件通知某人在对方系统里手动补上相应数据。 3. Idempotency. 发出请求后却没能收到对方的反馈，那对方倒底是处理请求失败，还是处理请求成功但发送反馈超时？ 本方系统不知道，因此不知道能否重发请求。为了解决这个问题，对方系统应该保证重复请求不会产生错误的结果，这样就不怕重复。
SalesForce: 无法与Lead建立Master-Detail关系 (Lead作为Master)
http://boards.developerforce.com/t5/General-Development/Needed-a-master-detail-relationship-with-lead-as-master-and/td-p/158941 Bummer!
SalesForce: 让subscriber在安装Package时指定一些参数？ 不可能！
我真失望！ 看这里： http://boards.developerforce.com/t5/AppExchange-Directory-Packaging/How-to-enable-subscriber-specific-settings-in-a-managed-package/td-p/261763 Re: How to enable subscriber-specific settings in a managed package? I don’t think there’s a way to collect the info during install. It would have to be a post-installation step. These instructions should be in your Customization/Installation guide. The place to store this type of information is in a Custom Settings record …
SalesForce: 一个Developer Edition只能有一个Managed Package(by 2011-3-28)
SalesForce中， 一个Developer Edition只能有一个Managed Package (今天是2011-3-28) 如果要开发多个Managed Package，就得建多个Developer Edition. 如果多个Package之间有代码共享，那就很．．．．．． 很多人都在抱怨： http://success.salesforce.com/ideaView?id=08730000000BqDaAAK
SalesForce中的Workflow其实就是业务触发器
SalesForce命名法真够雷人！ Workflow并不是让你定义什么工作流。它只是让你定义 “某种业务规则成立时可以触发什么事情”。 “业务规则”定义在Business Object上，比如 Account的姓名改成了"Obama" “触发事情”则不外乎改变一下某Business Object的值，分配一下Task，或者发封邮件而已。 所以说，它只是一个Trigger； 不过要注意， SalesForce中已经有Trigger 这个概念。这种Trigger是技术上而言的，它只在对象被持久化时触发；由于这种Trigger要用APEX来实现，因此又叫APEX Trigger ================================================ SalesForce还是支持自定义WorkFlow的，这在SalesForce里叫做 "Approval Processes"
SalesForce: 不同的Tenant之间不能有共同的用户名？
test@test.com如果是Tenant A的用户，就不能再成为Tenant B的用户。 今天试验时发现的。 但我可能对SalesForce中Tenant的定义理解有误。再看看
SalesForce: 两种访问控制机制结合
一般的系统中，一个User有好几种Role，每种Role有好几种Permission SalesForce.com中，这种机制仍然存在，不过这里的Role被称作"Profile" 同时User还有一种头衔，如CEO, VP,Manager等等，这种头衔被统称为"Role" Profile用来定义User对Object及其Fields的权限，比如 Standard User可以看Account，但不能删Campaign 而Role则用来定义User对具体哪些记录有权限。比如CEO可以看所有人的 Lead，而Manager A 不能看 Manager B的Lead