Salesforce的Trust终于改版了

trust site是由Salesforce提供,用来监控所有服务与实例状态的网站。

经典应用场景是,发现实例变得很慢,然后打开trust,哦。。。发生了性能降低。

新版trust也提供了新版API,可以获得相关实例的JSON串,自己定时获取,自己解析,可以实现自动提醒,自动警报。

API地址 https://api.status.salesforce.com/v1/instances/{你的实例名}/status

所有接口的说明 https://api.status.salesforce.com/v1/docs/

Salesfroce更新了Summer 16′ 版本的ForceIDE v37.0

官网地址:https://developer.salesforce.com/page/Force.com_IDE_Installation
更新日志:https://developer.salesforce.com/page/Force.com_IDE_Release_Notes

我在Eclipse Neon上已经成功更新。
本次更新的最大变更是。。。。更改了插件安装地址。没错。
还有提供了Lightning单独的开发组件。

另外,值得一提的是,启用了Java早就有的Open Type功能。

重点来了,打断点! Debug调式!没错!像个堂堂正正的Java程序员那样!
不过我还没试验这个新功能,之后会更新。

Salesforce的Auto Number

在Salesforce中新建Object的时候,可以对Name选择Auto Number,即自动编号。如果没有仔细阅读说明的话,会有一个很容易让人迷惑的地方。

在选择时候,Salesforce提供的示例为 示例:  A-{0000}。

那么问题来了,假设我如示例一样设定了4个0,那么当我的数据编号已经到达了A-9999会怎么样呢?

真实情况是,什么都不会发生,A-10000会被正常创建,A-10001也会被正常创建。

原因是这样的,A-{0000}的意思,是至少要有4位数字,不足则补零。例如,第99条数据的Name为A-0099。就是说,这个格式只是用来标注补零的位数的。。。不是用来限制编号最大位的。。。

然后,在设定是还可以输入开始数字,假设我设定从99999开始呢? 还是没关系。但如果设定的开始数字为1,000,000,000以上,则会告诉你,不能大于这个数。

OK,那我设为999,999,999。接下来创建数据会怎样呢?

没错,A-1000000000会被正常创建,在建一条,A-1000000001也出来了。。。。。。

所以不用担心编号用光的事情了。200多位。。。我觉得有生之前都不一定用得没了。。

Salesforce也有Explain了

Explain在各大数据库里,是调式SQL的利器。
虽然众所周知,Salesforce底层用的是Oracle。但从来没有开放过调用Explain的方法。

终于,有变化了!
目前作为一个beta特性,Salesforce将Explain放进了REST API
不过比较蛋疼的是,返回的是json,需要自己处理下。由于是beta特性,所以Salesforce不做任何技术支持。

<?php 
// Get your token via REST API 
$token = getToken(); 
$remote_server = "https://****your instance name****.salesforce.com/services/data/v37.0/query/?explain=*****your soql*****"; 
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $remote_server); 
curl_setopt($ch, CURLOPT_POST, false); 
$header[] = "Authorization:Bearer " . $token; 
curl_setopt($ch, CURLOPT_HTTPHEADER,$header); 
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); 
$data = curl_exec($ch); 
curl_close($ch); 
echo $data; 
?>

// 2016-09-28 Update1

其实在Salesforce Developer Console中早就有这个功能了。。。但是对于分析SOQL的瓶颈还是很有帮助的。

Salesforce中一条数据占多大存储空间

如果把Salesforce视为一个数据库的话,它与其他牌子的数据库不大一样。
按理说,不同的表因为字段数量不同,字段多的应该比字段少的占用空间要多。

但是Salesforce却无视字段数量,就是说字段数量不会影响到占用空间。
大多数情况,每条数据占用空间为2KB
但是还有例外

Leads — 2KB
Contacts — 2KB
Accounts — 2KB
Person Accounts – 4KB
Opportunities — 2KB
Forecasts — 2KB
Events — 2KB
Tasks — 2KB
Cases — 2KB
Case Team Member – 2KB
Solutions — 2KB
Notes — 2KB
Custom Reports — 2KB
Campaigns – 8KB
Campaign Members – 1KB
Contracts – 2KB
Google Docs – 2KB
Quotes – 2KB
Tags: unique tags – 2KB
Custom Objects – 2KB
Quote Template Rich Text Data – 2KB
Articles – 4KB

所以在进行存储空间估算的时候要注意例外的SObject。

Salesforce中简单的进行Callout的Scheduler

global class MyScheduler implements Schedulable{
    global void execute(SchedulableContext SC){
        CallOut.doCallout();
    }
}
public class CallOut{
    @future(callout=true)
    public static void doCallout(){
               HttpRequest req = new HttpRequest();
        HttpResponse res = new HttpResponse();
        Http http = new Http();
        req.setEndpoint(endPoint);
        req.setMethod('POST');
        req.setCompressed(false);
        req.setBody('');
        req.setHeader('Content-Type', 'application/x-www-form-urlencoded');
        res = http.send(req);
        // do something with res.
        }
}

Task上的IsArchive字段

Salesforce中会对符合条件的SObject进行自动的Archive。就是压缩。

官方文档的描述中,主要的条件为Closed超过365天。系统会自动的进行Archive。

具体的体现在,Task上会有一个字段叫做isArchived。如果task被系统Archive,此字段便会设为True。同时,此条数据无法在report中进行显示。但可以用Query All的方式获取。

以上是背景资料。

继续调查了一下,发现就算是被Archive,仍然占据储存空间。那么,是否与正常的数据占用的空间大小一致呢?还有,系统会在什么时候进行标记工作呢?是不是与储存空间的使用情况相关呢?

我进行了如下试验:

在一个干净的Org里,开启了Createddate可写,然后插入了一定量的状态为Connect/Closed的Task。确定IsClosed已为True。之后等。

结果:等待一宿之后,IsArchived字段毫无变化,可确定频率不是每日。

To Be Continue…

// 2016-06-08 Update1

经过和Salesforce技术支持的各种撕逼深度沟通,目前可以确认的是:

  1. 在Salesforce环境中的Storage Usage页面看到的统计数据是所有未被删除数据(正常数据+被Archive掉的数据)。总结一下就是说,Archive掉了仍然和正常数据一样占用空间(然后在Report里还变的不可见了,不加Query all也检索不到了,Salesforce搞毛线?)
  2. 被Archive只是代表被更改了一个状态位,并不影响储存(与正常数据一样占用2KB)
  3. Archive只针对Task等有限的几张表,具体的实施时间点是在每周六大概,系统自动执行。

这样的话,我们在清理task数据的时候,一定要用query all,并加上条件isdeleted=false。才是全部的目标范围。

Salesforce与Trigger的故事续篇

Selseforce与Trigger又有新的故事发生了。
目前没有官方文档对此现象有相关描述。

具体现象是这样的。
假设有一个Object叫做ObjectA,上面有个字段A__c是Lookup字段,比如Lookup Contact。
还有一个字段B__c是公式字段,公式的内容是A__r.Account.Id。

问题出在我们在ObjectA的Before Insert Trigger上,做了A__c的赋值操作。
如果我们在触发Trigger的时候,所插入的数据并没有对A__c进行过任何操作,在Trigger里对A__c进行赋值的话,在Trigger里取B__c的值居然是为空的。

如果我们在触发Trigger的时候,对A__c进行赋值,那么在Trigger里再次对A__c进行赋值,在Trigger里取得B__c的值的话,呵呵呵呵呵呵,里面居然是在触发前设定的那个Contact关联的Account的ID。就是说,在Trigger里更改A的值,并没有对公式字段B造成影响。

推断如下,
因为公式字段的内容为__r,所以需要在后台进行一次查询,但是因为在Trigger里,本条数据虽然还没有插入数据库,但是还是被锁住了,导致无法及时的更新公式字段的值。

或者,只要是进入了Apex代码范围,所有公式字段皆无法进行实时更新。

// Update1

已证实,只要进入Apex范围公式就不会更新,但会保留进入之前的计算结果。

// Update2 2018-01-12

写这篇文章的时候,貌似sfdc刚刚release了recalculate formula的函数。所以当时傻乎乎的以为没办法。现在知道了,直接调用SObject.recalculateFormulas()方法就好了。不过需要注意的是,cross-object的formula并不会被重新计算。

关于Trigger与Workflow的故事

Salesforce中,一个动作会触发一系列的处理。

在Salesforce官方文档里,有关于各个处理的处理顺序的描述。执行顺序的官方描述

其中有这么一种情况,如果有个Workflow的行为是更新字段的值,然后在此Object中有一个After Trigger,包括Insert与Update。

在官方文档的描述里,After Trigger是优先于Workflow的。

这样的话,会出现一种现象,当新建了一条符合workflow条件的数据的时候,Trigger中的Insert和Update会被先后执行。但是Trigger内部的话并不会出现这种情况,并且After Trigger是不允许更新本条数据的。

Workflow与Trigger的关系要捋清,要慎用。

// Update1 2016-06-08

Flow Chart