分类： Salesforce

不同与Java系统，salesforce给Select或者Drop down，whatever你叫它什么的那个元素提供了一个很好的组织方式———-Picklist。

Picklist作为一种基本数据类型，在salesforce里任何人都可以使用其轻松的创建下拉列表，并动态的控制其中的选项。要知道，在java系统里，为了达到这个目的，可是要上三大框架的。如果不能用自定义标签库，那么在不hard coding的前提下，在画面上可控的显示一个select对于一个新手来讲，将是一个堪比穿越撒哈拉沙漠的挑战。当然，大部分项目都选择直接写死，或者使用Js操纵DOM。

不过Salesforce的Picklist与我们印象中的Select元素还是不同的。

在Spring 17之前（Spring 17 release note），picklist的值只有一个value，所以表示文本也是它，值也是它。所以好多系统就顺水推舟的在代码，validation rule等地方直接用长长的value内容做判断。
突然有一天，客户想对选项的内容做一个小小的改动。。。。。灾难了。
以前的话，更改选项的值，既存数据是不会跟着变的，要手动修数据。现在已经能够做到既存的数据自动跟着变了。但是那些代码里写死的判断等就不行了。

我们知道，html中的select是要分别设定value和label的！在页面表示label，表单里传的是value。这样根据定义好的数据字典，在程序里随便判断value。无论画面表示的本文怎么改都不会影响到程序。

所以sfdc的先贤们发明了一个绝招————翻译。

比如picklist的一个项目的value是1，则在翻译控制台将1翻译成想显示的文本，比如“A”。那么就实现了HTML的Select的特性—–显示的文本和后台传值分开。

正当群众们洋洋得意的时候，Spring17来了。给我们带来了picklist选项的Api Name，参见官方博客。

抱歉，说的不严谨，应该是给我们带来了Picklist选项的Label。

就是说现在Picklist的选项有两个设定值值，一个是Label，一个是Api Name。Api Name其实还是我们以前熟悉的那个选项value，老朋友。新增加的是Label。

那么好玩的地方来了。以前Picklist选项只有一个value的时候，翻译就直接那么翻译了。当Label和Api Name分开之后，翻译是针对谁来进行翻译呢？

这里直接公布答案—–是Label。

可以用下面的代码进行尝试。

 
设定好翻译之后

List<Schema.PicklistEntry> picklistValues = SomeSobject__c.SomePicklistField__c.getDescribe().getPicklistValues();
for (Schema.PicklistEntry pe: picklistValues) {
    system.debug('PicklistEntry Value:' + pe.getValue() + ' Translated Label:' + pe.getLabel());
}

value既Api Name，Label既Label

这样，我们是可以做到在Apex中获取Picklist选项的Label，而且获得的还是翻译后的Label。
可曾记起我们还有Formula呢，isPickVal函数判断的又是谁呢—————没错，还是老朋友，Api Name。
目前我还没有找到如何在formula里获取Label名的方法。

一般来讲，就算是DevOps团队也很难遇到需要删除Apex的情景。
毕竟在一个系统的生命周期里，大部分时间都是不断的增加功能，或者改动现有功能。
仅剩的一点点的遗弃功能的需求，也会因为考虑到风险问题，从而选择将废弃代码放在那里不再调用。
毕竟，维护团队的准则————不动就没事，动了就要担风险。

其实，还有一种需要删除Apex操作的情景，就是回滚。
Salesforce与常规的Java项目不大一样，如果上线出现问题，很难做到完美回滚。
曾经有人很天真地和我说，将生产环境的MetaData全部备份，如果上线出问题就全都deploy回去。
java web系统确实可以这么做，一个新版war包，一个旧war包，出问题就停机覆盖回去，一切就都恢复如初了，完美。
可惜，如果Salesforce这么做就会面临一场巨大的灾难！
首先，你有很大的几率会彻彻底底的失败。因为Salesforce在deploy的时候要计算metadata之间的关系。
你会因为各种狗追尾巴似的关系依赖，导致失败，继而崩溃。
还有一些永远无法被正确Deploy上去的metadata，会将你的生产环境毁成一片废墟。
在Salesforce里，只要是稍微复杂一点的Org，就永远不要幻想将全部的Metadata都一口气deploy上去。

话说回来，Salesforce最安全的回滚方式还是逆操作。就像录像带的倒放。
但是，就算是逆操作，仍然不能保证安全的，原原本本的回到从前，尤其是回滚包含修复数据动作的时候。
所以在上线之前，针对回滚，认认真真地制定一个回滚方案是非常，非常有必要的。
当然，如果你每次上线只是加一个Field，当我没说。
不过，就算是只删一个Field的话，慎重吧。

回到正题，怎么去删除一个Apex。
有的同学说了。直接删就好了啊。
那么。。。只接触过Developer环境和Sandbox的可以出门右转了。生产环境是无法直接删除的。

那么，下面，先讲一个简单的方法。

首先，我们有一个ApexClass，叫DeleteSample。

然后在ForceIDE中，新建一个Project，将其MetaData取下。

之后打开此Apex，之后切换到Metadata标签上。

然后将Status从Active改成Deleted

然后，保存，在Apex上点右键，Force.com -> Deploy to Server。

之后填入用户名密码，下一步，强调一下，被删除的Apex会被标记成Overwrite，且默认不被选中。如果是新建的代码则会被标记成New，绿色，自动勾选。修改的代码被标记成Modify，黄色，自动勾选。这里，一定要记得钩选上。

然后无脑下一步，直到看到Success。

然后回到系统里，就发现DeleteSample已经不见了！

就这样。简单吧。

 

(上密码遭人恨。。。。先开放好了)

由于role不同于Profile，带有阶层性质，所以有一些自定义功能要依赖于这种阶层的设定。这样就涉及到role hierarchy的判断问题。

我是一个绝懒之人，所以去网上搜了一下，能找到的方案都或多或少有些缺陷 。

我所提供的方案也是如此，但是想比于浪费太多SOQL查询次数来讲，role的数量不超过50000条已经是足够好了。
// 这里Update一下，其实根本不会有那么多的Role，因为默认500，提票才能达到10000。

Talk is cheap, show you the code.
PS:最近正在建设个人代码库，本身也只是一个简单的示例，之后会放出完全体版本。
也许也会放到Github上。

// @Version 0.1 Author Keal. Email: [email protected]
// @license http://www.gnu.org/copyleft/lesser.html GNU Lesser General Public License
public class RoleHierarchyHelper {
	Boolean isEnd = false;
	Boolean compareResult = false;
	public static List<UserRole> roleList = [SELECT Id, Name, DeveloperName, ParentRoleId FROM UserRole LIMIT 50000];
	
	public RoleHierarchyHelper() {
		// pretend Salesforce spasms LOL. It happened.
		if(roleList == null || roleList.size() == 0) {
			roleList = [SELECT Id, Name, DeveloperName, ParentRoleId FROM UserRole LIMIT 50000];			
		} else {
			system.debug('=======RoleList.size()========' + roleList.size());
		}
	}
	
    public Boolean isSubordinate(String currentRoleId, String compareRoleId){
    			
	    List<UserRole> childRoleList = new List<UserRole>();
	    Map<Id, UserRole> childRoleMap = new Map<Id, UserRole>();
	    Set<Id> exeUserRoleIdSet = new Set<Id>();
	    exeUserRoleIdSet.add(currentRoleId);
	    
	    isEnd = false;
	    compareResult = false;
    	while(!isEnd) {
			childRoleMap = new Map<Id, UserRole>();
	    	for(UserRole ur: roleList) {
	    		if(ur.ParentRoleId != null && exeUserRoleIdSet.contains(ur.ParentRoleId)) {
	    			childRoleMap.put(ur.Id, ur);
	    		}
	    	}
	    	
			if(childRoleMap.size() > 0) {
				if(childRoleMap.containsKey(compareRoleId)) {
					isEnd = true;
					compareResult = true;	
				} else {
					isEnd = false;
					exeUserRoleIdSet = new Set<Id>();
					exeUserRoleIdSet.addAll(childRoleMap.keyset());			
				}
				
			} else {
				isEnd = true;
				compareResult = false;
			}
    	}
    	return compareResult;
    }
    
    public Boolean isSuperior(String currentRoleId, String compareRoleId) {
    	Map<Id, UserRole> idUserRoleMap = new Map<Id, UserRole>(roleList);
    	Id exeUserRoleId = currentRoleId;
    	UserRole exeUserRole = new UserRole();
    	
	    isEnd = false;
	    compareResult = false;
    	while(!isEnd) {
    		exeUserRole = idUserRoleMap.get(exeUserRoleId);
    		if(exeUserRole.parentRoleId == null) {
    			isEnd = true;
    			compareResult = false;
    		} else {
    			if(exeUserRole.parentRoleId == compareRoleId) {
	    			isEnd = true;
	    			compareResult = true;
    			} else {
	    			isEnd = false;
	    			exeUserRoleId = exeUserRole.parentRoleId;
    			}
    		}
    	}
    	return compareResult;
    }
    // TODO isSameLine()
}

在Salesforce中建立Scheduler的方式有两种

1. 在Develop->Apex Classes页面，点击Schedule Apex按钮之后会提供如下的面板。
   
   这个面板虽然能方便的决定Scheduler执行的频率，但是最高频率也只能是一天一次。
2. 再有就是使用Apex。在匿名块中使用系统函数设定Scheduler，可以获得更高的频率。

所以，如果想设定一小时执行的Scheduler就必须使用第二种方式。
需要使用的函数为System.schedule();
官方文档对此进行了详细的描述。具体参照下列示例代码。

// Sample 1 hour 1 time
System.schedule('My Scheduler','0 0 0/1 * * ?', new MyScheduler()); 

作为一个成熟的完善的系统，定时器与后台Job是必须的组成部分。
Scheduler就是Linux Cron的强力山寨。
所以System.schedule()中的第二个参数，就等同于Cron表达式(当然，只能算一个子集)。

为什么要把一小时一次单独拎出来，因为，这是Scheduler的最小粒度。
Scheduler表达式的秒位与分位是不支持“/”符号的。

所以，想几分钟执行一次的，放弃吧。