Monthly Archives: March 2011

不推荐的作法:数据库里把ID设为Number类型,Java里设为字符串类型

ID一般是自增的,所以数据库里应设为Number类型

Java里可以把它置为String类型,因为ID纯粹是一个标识,并没有数字意义(不参与加减乘除)

然而这里有个小陷阱:类型转换时会出问题。

数字格式化为String时可能会产生逗号,带逗号的String未必能舒服地转回成数字。 当你的系统与另外一个系统交互,且另外一个系统要求ID为数字类型时,这种问题就可能成为灾难。

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: 让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 marked as Protected. You’d typically create a VF page that collects the info from the user and stores it in Custom Settings.

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: 两种访问控制机制结合

一般的系统中,一个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