俗话说，标题不长没人看。
不过这篇只是做一个存档，方便分享传阅，并没有故事。

如果使用VS Code选择了SFDX Create Project with Manifest，并且使用git进行代码版本管理，建议使用如下.gitignore

/*
!.gitignore
!anonymous.apex
!/force-app
!/manifest

此配置只追踪代码所在文件夹和package.xml所在文件夹。能有效的加快git处理速度。

// Update
解释：
Line 1 忽略此路径下所有文件夹，所属文件，及子文件夹及所属文件
Line 2 不忽略自己(.gitignore)
Line 3 VScode支持apex后缀的文件作为匿名块。所以你可以配和sfdx的命令愉快的储存匿名块重复使用了。公用的匿名块放在anonymous.apex同步到repo，私用的新建一个新的不同步到repo。
Line 4 不忽略代码所在文件夹及所属文件，及子文件夹与所属文件
Line 5 不忽略Package.xml所在文件夹及所属文件，及子文件夹与所属文件

1. 页面后台两不同，
2. 布局规则最优先，
3. 格式长度和必填。
4. Before Trigger触发前，
5. 后台只将外键检。
6. 批量插入有例外，
7. 验证规则提前验。
8. Before之后做验证，
9. 自定规则和必填，
10. 系统规则不二遍。
11. 验证之后跑去重，
12. 存入DB不提交。
13. After Trigger触发后，
14. 分配/回复/工作流，
15. 如果字段有更新，
16. 验证/去重不再做，
17. Trigger仅再跑一次。
18. PB/Flow依次跑，
19. 数据操作从头走，
20. Case规则在随后。
21. 父表汇总此时算，
22. 工作流把父表更，
23. 共享规则重计算。
24. 数据DB提交后，
25. 后续邮件才发送。

// 逐句解释更新中……
解释：
行1，行2，行3：与使用apex或者api新建或者更新数据相比， 通过Page Layout新建或者更新数据的行为会少许不同。通过Page Layout的时候会根据layout的字段属性配置提前进行一次字段格式（比如邮箱类型，电话号码格式等）/字段长度/字段是否必填等检查，才会进行后续的Trigger处理。
行4，行5：对于通过Apex或者API等方式后台创建/更新数据，虽然不会提前做一次系统级检查，但会对外键做一次检查，确保没有发生引用自己的情况。
行6，行7 ：按理说接下来无论是用过Page Layout还是通过后台，下一步都应该进入Trigger处理了吧？还不一定。这里有一个例外形况，就是如果发生了例如Opportunity Line Item或者Quote Line Item的批量创建，则会提前执行一次自定义的Validation Rule。

官方文档地址: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm

某日，一个悠闲的午后，我泡的一杯毛尖正在阳光下散发着热气。嗯，接到一个小活儿。平平稳稳，不需要经历大风大浪，不需过五关斩六将的小活儿——-导数据。

这次需要更新的数据是Product。就是那个标准SObject，Product2，三位prefix是01t。人们常说用标准SObject用多了总会遇见坑，但人生又何尝不是如此。不是
完全控制在自己手里的东西，只能去了解，去接受，最后习以为常。

果然，这次就掉坑里了。工具执行结束之后，一看Log。在1000条数据里面，有50多条报了如下的错误。
StatusCode: CANNOT_CASCADE_PRODUCT_ACTIVE
Error Message: Cannot update associated pricebook entries without the Manage Price Books permission
然后看了下报错的数据，也没什么特别明显的特征。 貌似是无差别报错。

唔。。。万事不决查文档。
很快就在《SOAP API Developer Guide》定位到了这个Status Code。
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_concepts_core_data_objects.htm

CANNOT_CASCADE_PRODUCT_ACTIVE
An update to a product caused by a cascade can’t be done because the associated product is active.

《SOAP API Developer Guide》

咦？怎么详描述的与系统返回的信息不一样？

系统反馈给我的信息是“由于没有Manage Price Books Permission, 所以无法更新关联的Pricebook”。只是说由于我没有Manage Price Books权限才报错，但是我更新Product为什么又会在意我有没有Manage Price Books的权限？

而文档给的信息是“由于product是active，所以无法完成由联级更新引起的被关联的product。 ”这写的是啥啥啥？什么叫caused by a cascade，谁是发出动作的人？是我的话我又cascade了谁？谁又Associated了我？

既然《SOAP API Developer Guide》的描述完全不知所云，那么就从系统直接反馈的错误信息入手吧。查了一下使用的账号，Profile和Permission上确实都没有PriceBook的CRUD权限。不过。。。。如果是因为没有PriceBook的权限的话，为什么绝大部分数据还更新成功了？如果真是这样，由于我没有权限，应该一条都不会成功才对。

结合两条截然不同的信息来看。线索指向了两个关键点。
1. PriceBook的权限。
2. Product的active状态。

于是做了一个试验，在没有PriceBook编辑权限的前提下，尝试去变更Product的active状态。果然报出的相同的错误信息。
就是说，如果想更新product的active状态，需要Pricebook的编辑权限。
唔。。。。

故事当然没有到此结束，不甘心的我突发奇想的在本地硬盘搜索了一下这个status code，结果在一本上古文档里发现了这样一段描述。

CANNOT_CASCADE_PRODUCT_ACTIVE

You cannot activate or deactivate this product without also being able to edit pricebooks.

某上古文档

原来错误信息还有第三个版本。这个版本明确的指出了问题的所在。

接下来是无责任脑洞推理。没有任何实锤和Evidence。

在Salesforce中，Product和Price Book是多对多的关系。一个product可以有多个Price Book，而Price Book也可以包含多个Product。Price Book Entry就是二者的Junction Object。
如果用workbench查看Price Book Entry上关联Product与Price Book的字段的关系属性，会发现该关系具有联级删除属性(cascadeDelete: true)。
所以在此推定Product与Price Book Entry，Price Book与Price Book Entry之间的关系皆为Master-Detail。
在表权限层级。

在Profile中，如果想要拥有子表的编辑权限，那么至少要拥有父表的View权限。反过来，如果连父表的view权限都没有，则子表没有任何权限。

所以，由于我没有Price Book的任何权限，导致失去Price Book Entry的所有权限。
而根据观察，Product在active状态变化的时候，会同步active状态到所有旗下的Product Book Entry。
在此推测Salesforce在Product上加了一个Trigger/Workflow/Flow/Process Builder用来用来同步active状态，而且在这个处理中特意做了权限检查。如果发现没有Price Book Entry的权限，则去检查Price Book的权限，如果也没有权限，就报错。

这也正是系统直接返回的错误信息的由来：

Cannot update associated pricebook entries without the Manage Price Books permission

至于为何错误信息出现这么多版本，我推测是由于与Product有多对多关系的不仅仅只有Price Book，所以同一个StatusCode从单一情景变为也会复用在其他的情景。所以错误信息在文档里就改成了更加泛指的版本。而这次我遇见的错误是一个很具体的场景，则出现的信息又由泛指的版本变为更加具体的版本。

脑洞完毕。我去加权限了。。

某日，又见某童鞋双手合十，指尖杵在下巴上，做福尔摩斯状。
忍不住凑了过去 。
此童鞋用眼角瞄到有人过来了，嘴角抽动了一下，欲言又止。

“别难为自己了，说说吧。”团结才是力量，对不对。
“好吧。。。”他长长的吐了一口气，手也放了下来。“事情是这样的，我有一张表叫做order。这个order有个字段叫product，会去lookup一个叫product的表。”。说着，他打开了SObject的详细页面。“现在我需要导入历史订单数据，量很大。”

我点了点头，示意他继续，因为目前为止听起来没什么。
“问题是原始数据的product字段并不是product的id，而是product的code。这样的话我没法直接导入系统。” 在我开口之前他赶紧抢先又说道，“product的种类和order的数据量都实在太大了，实在没办法用vlookup处理。已经死机好几次了。”

我弹开了他的手，接过鼠标打开了product表的定义页面。在自定义字段中找寻那个叫code的字段。唔。。。。External Id勾选了，Unique勾选了。不禁扬起了嘴角。

“看，Product的code是external Id。”我指着屏幕。
“可是我们要导入数据的是Order啊，不是Product。”
“那你先说说看，External Id在Dataloader里怎么用？”
“就是Upsert的时候，可以指定External Id，如果匹配上了就update，没匹配上就insert。”他自信的回答道。
“没错。但是还有一种用法。”
“啊？”

众所周知，lookup字段实际储存的值为ID。这也就意味着，在insert或者update数据的时候，我们要将Id写在lookup字段上。如果写的不是Id，或者Id不存在，Dataloader会告诉我们数据写入失败。
一般的情况下，如果我们只有被lookup的表中一个字段的值(Product Code)，就不得不先根据这个值(Product的Code)去查出被lookup表的id(Product的Id)，然后放在待更新数据的lookup字段上(Order的Product字段)，才能继续执行下去(Order)。

不过，老天关上了你的门，一定会打开你的窗，毕竟你才是你生活的主角，所以有主角光环。

事实上，如果你拥有的值(Product Code)是被Lookup表的External Id(Product的Code)，那么在插入数据时，可以让Dataloader根据External Id自动的将lookup字段填入对应的Id。这样就不用人工的去查找替换了。

做法如下。
1. 首先，一如往常，准备好csv，点insert，输入账号密码，选择Order，选择csv路径，下一步。
2. 然后，Create or Edit a Map, Auto-Match Fields to Columns。
3. 接下来就不一样了。在匹配完字段时候，点击Save Mapping。选择路径，填入文件名。保存sdl文件。
4. 找到刚刚保存的sdl文件，用文本编辑器打开。修改如下。保存。

#Mapping values
#Wed Apr 24 19:13:21 CST 2019
# Old 
#PRODUCT__C=product__c
# New 
PRODUCT__C=product__r\:code__c
.........

5. 回到Datalaoder，关掉Mapping Dialog窗口，这次点击Choose an Exsiting Map，选择刚刚保存的sdl文件。
6. 一路next。
7. 恭喜插入成功。（如果Product Code存在的话）

“看，你与成功之间只差一个\:”。我拍了拍了他的肩旁。
“恩人慢走”。

总结：
1. 被lookup表需要有External ID。
2. 在SDL文件中，将lookup字段的__c变成__r（标准字段去掉Id），加上“\:”，加上External Id的API Name。insert或者update的时候使用此sdl。
3. 必须仅且只仅匹配到一条记录才可以成功写入。

参考官方文档：
https://help.salesforce.com/articleView?id=000002783&type=1

后记：
有人问我说，唉，明明写的技术相关的内容，文风为什么这么不正经？
其实原因不外乎两个。第一个是想看正八经儿的说明文就应该去看官方文档，而不是等着官方文档的翻译。Salesforce的文档和知识库是很强大和全面的。第二个是每一篇文章的灵感来源都是真实被提出过的问题，我觉得自古以来，最好的承载知识的方式就是带入情景，讲故事。官方文档似的说明文是告诉你怎么一步一步的用锤子钉钉子，而我是想用故事告诉你可以用锤子来解决钉钉子的问题。
总之，想要一个工具速查手册的话，应该去看官方文档知识库才对。

在去年年初，我们曾经讨论过Salesforce 15位ID与18位ID的话题（《关于salesforce的15位id与18位id》）。
那时候简单介绍了Salesforce的Id的组成，比如头三位为prefix，4到6位为instance code，校检位，18位ID的特性是case safe而不是大小写不敏感，等等。
那么有没有想过，Salesforce是如何知道某个字符串是不是合法的ID的呢？

虽然Apex里有Id与String两种数据类型，但是两者之间的关系却是如此暧昧与纠缠不清。
很多时候本应当使用Id型变量储存Id值，我们用String型变量去储存，然而也不会出问题。
再比如说，在SOQL中，我们在where语句中可以这么写…WHERE Id = ‘0016F000035LFXo ‘…干脆就是用的字符串。
如果是在Apex中，我们也可以使用变量…WHERE Id =: myId …，这里的变量myId无论是Id型还是String型也都不会有问题。所以粗略的看，似乎当作是一回事也没关系。

但是，如果我将字符串”ABCDEFG”赋值给ID型的变量，会怎么样呢？
如我们所料，会报异常，“ System.StringException: Invalid id: ABCDEFG ”。
这说明ID数据类型还是会对Id做合法性检查。
所以引出了最开始的问题，Salesforce是如何知道这个字符串是不是合法的ID的呢？