也就是说，Package Provider自己跑这个程序时，可以看到日志； 而Subscriber在使用这个包时，就看不到任何日志。。。。。。 也就是说Provider无法通过日志为Sucbscriber 做Debug SFDC的人在想什么？ 真蠢！ p.s. 这个问题在2010年就有人提出来了 http://success.salesforce.com/ideaView?c=09a30000000D9xtAAC&id=087300000007Py4AAE
要这样执行： namespace.class.method(); 比如 testpackagenamespace.testObject.testMethod();
这里是答案： http://boards.developerforce.com/t5/AppExchange-Directory-Packaging/Packaging-Users/m-p/136713#M1899 From the app: Profile Settings include object permissions, field-level security, and layouts, that map to the installer’s selected profiles during installation. The profile itself will not be installed. In other words, packaging profiles will not create a new profile in the destination org. Instead it allows you to map the new profile settings …
随着软件的进化，开发者可能会想删掉一些用不掉的软件组件，以保持软件的洁净、无误导性。 但这在SalesForce的Package里没那么容易办到，因为大部分组件都不准删除。比如Custom Object, Custom Field等等。 所以，开发SalesForce Package时，不要太敏捷。
ID一般是自增的，所以数据库里应设为Number类型 Java里可以把它置为String类型，因为ID纯粹是一个标识，并没有数字意义（不参与加减乘除） 然而这里有个小陷阱：类型转换时会出问题。 数字格式化为String时可能会产生逗号，带逗号的String未必能舒服地转回成数字。 当你的系统与另外一个系统交互，且另外一个系统要求ID为数字类型时，这种问题就可能成为灾难。
你用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中。
摘自《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已经存在了，就不要再执行相应的操作。
为了让两个交互的系统能够减少耦合，它们之间的消息交换方式应该尽量松散。 为了使交互变得松散，可以采用以下手段或者遵循以下准则： 1. One-Way Messaging. 即异步调用。一个典型的例子就是request/callback: 给对方系统发一个Notification，让对方在它方便地时候回调我们，拿它想要的东西 2. Compensation. 为了保证事务的原子性，一般可以采取“两阶段提交”手段； 但这种手段要求两个系统都要使用相应的基础设施，比较麻烦； 替代方案是在发生单边数据时采用Compensation操作： 要么系统自动把本方已生成的数据取消，要么发一封邮件通知某人在对方系统里手动补上相应数据。 3. Idempotency. 发出请求后却没能收到对方的反馈，那对方倒底是处理请求失败，还是处理请求成功但发送反馈超时？ 本方系统不知道，因此不知道能否重发请求。为了解决这个问题，对方系统应该保证重复请求不会产生错误的结果，这样就不怕重复。
http://boards.developerforce.com/t5/General-Development/Needed-a-master-detail-relationship-with-lead-as-master-and/td-p/158941 Bummer!
我真失望！ 看这里： 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 …