基于 Facebook 发送业务单据的设计及实现

2016-12-16 15:35:00

商业活动中，有太多类型的信息，需要通过电子方式发送给客户，比如车票、机票、酒店订单、餐厅小票、银行对账单、收据、发票、催款单、通知等等。邮寄信件是电子方式之前的古老手段，已经逐步退出历史舞台。今天占据主流的是电子邮件，还有手机短信。随着智能手机越来越流行，越来越强大，电子邮件和手机短信，也渐渐没落。喜新厌旧的人们，将大部分时间都消耗在社交平台和聊天工具上。

所以，社交平台和聊天工具开始成为商业票据单证信息的主流发送渠道。对于 ERP、CRM、电商以及各种行业里的业务处理平台，能够根据订单自动发送业务信息到主流的社交平台和聊天工具，就是一种强烈的需求了。

从世界上最流行的社交聊天工具中，选取 Whatsapp 和 Facebook Message 作为考虑目标。Whatsapp 在全球有10亿人应用，遍布180个国家。但是遗憾， Whatsapp 的策略是 No API，就跟中国黑暗愚蠢的古代一样闭关锁国，那时海上有海禁，陆上有长城，严严实实封的跟猪圈似得。遍搜互联网，也能找到很多程序员们写的 Whatsapp 破解程序，但要么不好用，要么过时了。Whatsapp 在封堵上三手都很硬，一手堵漏洞，一手封手机号，还有一手就是律师函威胁开发者。2015年有一款 Whatsapp 破解应用叫 Yowsup，用 Python 开发的，用起来效果很好，架起来跑了几个月，往 whatsapp账号里发消息迅捷如风，但在 2015 年冬，Yowsup 卒！

最终还是放弃了 Whatsapp，树一根中指给 Whatsapp！真是不可理喻，不提供 API 的互联网应用真是不可理喻！可疏不可堵这个中国人都懂的道理，Whatsapp 不懂。程序员何苦为难程序员。

Facebook Messager 是唯一的选择了。全球超10亿用户，有井水处就有 Facebook，除了猪圈没有井。Facebook 也比较凶悍，2014年推广 Messager 的时候，强制 Facebook 用户必须下载 Messager，一下子把 Messager 用户推到了10 亿。

Facebook 是 Facebook， Facebook Messager 是 Facebook Messager，两个独立应用。

Facebook Messager 有 API 么？当然有！小扎 Zuckerberg，每天都在絮叨： Connect People。连接全世界，是 Facebook 的使命，当然不缺 API 了。 Facebook 的 API 简直丰富到爆炸。

访问这里：https://developers.facebook.com/

令人眼花缭乱。而这就是做 Facebook 集成的第一个难题，需要根据自己的需求，从众多的 SDK，API 中挑选自己适用的。

为的从 ERP，CRM 之类的Web或者桌面系统，发送业务信息到 Messager，那么适用的是 Graph API:

Graph API 文档也是一大堆，不过 Facebook 很贴心的提供了一个工具叫 Graph API Explore:https://developers.facebook.com/tools/explorer

有了这个工具，玩一会就搞清楚了各个 API 的用法。

接下来，要考虑如何实现信息发送了。首先要清楚一个残酷的现实，那就是 Facebook 再有善意，也不会允许通过 API 任意发送短信到陌生人的。这就没法做到电子邮件和手机短信那么灵活，电子邮件和短信一方面垃圾堆猪圈一般航脏爆满，另一方面人们还真不能彻底抛弃这两者，因为只有它们才能实现陌生人之间的联系，所以它们俩永远都是个起点......

在 Facebook 平台上，即便以某个账号的身份，通过 API 群发消息给好友，也不可以。

只有一种途径可以行得通。那就是通过 Facebook Page 来收发消息。 Facebook Page 是专为推广商业所用，有点类似微信的公众号，但是理念和功能又全然不同。 Facebook Page 必须基于一个个人的 Facebook 账号创建，一个 Facebook 账号可以随意创建很多个 Page。Page 更准确的说，是一个基于 Facebook 个人账号的商业主页，或者商业子站。可以像打理个人网站一样打理 Page。下面是人民日报在 Facebook 上的 Page:

别的功能不去管它了，只看怎么发消息。 Page 可以接受和发送消息给其他 Facebook用户，前提是，只能回答别人发给 Page 的消息。这和微信的策略是一样的。只能回答别人的消息，不能主动发送消息给别人。和微信不同的是，Page 不可推送群发消息到粉丝，只能发帖子在自己的时间线上，当然帖子也会出现在粉丝的时间线上。

而且，当一个 Facebook 用户给一个 Page 发送消息后，就构成了一个对话（ Coversation），据观察，该对话具有唯一的 ID，且永远不变。这样，Page 在任何时候，就可以对一个已有的对话，发送消息。

但另一个困难的问题出现，Page 如何辨认和保存对话另一方的 ID 呢？Facebook 虽然也可以自行设置唯一的用户名，但大部分的用户都没有也并不知道此功能。Facebook 用户与 QQ，微博，微信用户的行为习惯不一样，他们不会在见面的时候问：您的 Facebook 号是什么？ Facebook 用户之间建立联系是通过电话、邮件以及姓名搜索实现的。

当一个客户给你的商业 Page 发消息，要买你一亿美金的面膜，你可能根本查不出这客户是谁，更没法和你 ERP，CRM系统里的客户档案匹配上。另一个场景中，你的 ERP 或者 CRM 里有一个客户，你想给他的 Messager 发一张优惠券，你知道这个客户已经在 Facebook 上，但你只能到 Facebook 上一个个去辨认......

将第三方系统中的客户档案信息，与 Facebook中的客户建立关联，这是一个难题。与邮件系统和短信系统建立关联很简单，只需索要客户的邮件地址和手机号，然后存在系统中就行了。而对 Facebook 就不行，因为最麻烦的是，客户并不知道自己的 Facebook 唯一标示。

有很多种方法可以解决此问题，比如让客户在 Page 上发送自己的邮件地址、手机号（邮件地址和手机号必须与客户档案中的一致），然后从 Page 获取信息后，进行解析，与ERP系统匹配后，给该邮件地址或者手机号发送一个验证码，客户将此验证码发送回 Page 上的对话，API 获得此验证码后进行验证，然后保存客户的 OpenID和 ConversationID。这种方法的弊端是过程复杂。

还有一种方法是，请求客户在 Page 上任意发送一条消息，通过 API 截获消息后，可以获得该客户的 OpenID，通过 API 再将该 OpenID 发送消息给客户，请求客户通过邮件或者电话告知客服该 ID（ID的形式是：255390001542389），客户将ID存在ERP和CRM的客户档案中，就此建立关联。这种方法的弊端是需要人工干预，好处是验证身份较为准确。

OpenID 并非用户的唯一ID，而是用户针对一个 Facebook App 的唯一ID。用户张三，若是用了10个 App，那么每个 App 上的 OpenID 都不一样。

若要使用 API 访问 Facebook，就必须在 Facebook 开发者平台上，注册一个 App。不论你的 App 是手机上的 App，还是一个 Web App，都必须在开发者平台上先注册。

通过 App 管理平台，开发者就可以获得 App ID，App Secret，这是 API 访问必不可少的。还可以在这里设置管理员，开发团队，回调地址，以及设置该 App 需要应用的功能和权限等。

需要设置的东西不很多，但都得一一琢磨透了。比如为了实现对 Page 上接受信息的截获，就要用到Webhooks，这个功能让 Facebook 在 Page 收到消息后，主动发送通知到你的 App 回调地址。在 Webhooks 推出之前，第三方应用只能一遍遍的去查询调用，以实时更新。

App 需要通过 Facebook 的评审，才可以针对公众发布。但是做一个基于 Web 的，针对 Page 进行消息发送的服务器端工具，就可以免于评审了。因为你的所有消息搜索和消息发送的 API 调用，都可以用一个身份进行，也就是该 App 的管理员身份，而并不公开给所有 Facebook 用户。但对于游戏之类的 App，那就得通过评审了，因为那个App是给大众用的.....

大致的应用场景图如下：