曾经有朋友在知乎上向我提问，咨询在SAP成都研究院工作的体验。

当时，我的回答提到一点，SAP注重工作与生活的平衡，这也是SAP中国官网强调的一点。

https://www.sap.com/china/about/careers/who-we-are/life.html

具体到SAP成都研究院，这里的同事们业余时间的兴趣爱好广泛，既有传统的足球，篮球，羽毛球，游泳这些，也有门槛相关较高的铁人三项运动，详情可以参考SAP成都研究院铁人三项大神邓阳的文章: SAP成都研究院的体育故事。

当然，这些每天从事创造性工作的程序员当中也不乏身怀绝技之人，比如能够双手同时使棍的许聚龙:SAP成都研究院许聚龙: Hello, Coresystems；有痴迷于各种飞机的哈公子: SAP成都研究院飞机哥: 程序猿和飞机的不解之缘；有海归青年，深受法国浪漫主义熏陶，喜欢游泳摄影网球滑雪的陈扬洋；最近SAP成都研究院几期Toast Master活动，每期都有层出不穷的才艺带给大家的前端开发程序媛Feng Grace，喜欢烹饪美食，会弹奏夏威夷小吉他(乌克丽丽)，爱好摄影。下面两张图是Grace的作品:

当然谈到我们成都同事各式各样的兴趣爱好，一定少不了李晓刚：读佛经，写诗(打油诗)，玩飞镖，最近又迷上了囤积生土豆。

今天文章的作者，我的同事廖婧，是一位拥有十多年工作经验的SAP从业人员，专业技能的精通自然不用多说。生活中的廖婧，如果要让Jerry用一句话评价，那就是: 贤妻良母。

当然组里同事李晓刚对她的评价，Jerry也完全同意。

她的兴趣爱好或许不如前面几位同事那么吸引眼球，但是特别有意义——廖婧是成都小红马儿童会创始元老会员之一。小红马儿童会2011年1月创建于成都，是向弱势儿童和贫困乡村儿童提供服务的非营利性儿童关爱公益组织。关注对象为弱势儿童和乡村儿童，弱势儿童包括残疾儿童、孤弃儿童、少数民族儿童及留守儿童等。目前小红马的主要活动地在成都市周边贫困乡村。

更多关于小红马儿童会的信息，还是让廖婧给大家介绍吧。

下面是她的正文。

大家好，我是廖婧(Janet Liao)， 本职工作是一名SAP从业人员，业余时间喜欢做手工，包括除针线活以外的一切手工，像沙画、软陶、魔术气球、乐高等等，堪称小朋友杀手^_。 而这些“特殊”技能的习得，全靠这几年志愿者经历的锻炼。10年辞职旅行去了雨崩徒步，完了转头去双廊看新开了客栈的朋友，狗哥是当地“蓝脚印”的组织者，免费为志愿者提供住宿，很有幸的我成为了入住的第一批蓝脚印，往返两小时的山路，陪小朋友们弹琴唱歌画画踢球，充实快乐。

公益本应是普通生活的一部分，而不应带有任何的道德优越感，我们不是在施，而是在这些经历中得到了成长和喜悦，感谢这段旅行带给我的开悟。

回到成都之后，非常幸运地认识了一帮可爱的马儿们，成为“小红马儿童会”的“元老”成员，于是从11年开始了每月一次的乡村行，我们的愿望很简单，希望能陪伴父母不在身边的孩子们一个有色彩的童年，并对确实有需要的困难家庭进行家访并寻求助养人。感谢之前IBM的同事小强，不仅资助一个我家访过的孩子至今，还认真地为她考量合适的专业创造实习机会，真正使她们可能改变命运。抛开这些物质上的帮助，其实活动宗旨是陪伴的同时让孩子更多地了解自己的乡村，去发现、挖掘家乡文化，保持与家乡的情感链接，从而建立自己的文化自信。于是，我们有了各种文化小课，做标本、画石头、家乡的声音、家乡的色彩、家乡的味道，夏令营、冬令营，再到了后面的经典诵读。在这个过程当中，我们自己的收获比村里的孩子们要多得多，除了一群志同道合的朋友、发现美的能力，还有那么真诚热烈的被需要的感觉。当妈妈之后，活动参加得不多了，但是新生代马儿们还在继续，欢迎同样热爱乡村热爱生活热爱经典国学的朋友加入。

对这项公益活动感兴趣的朋友，可以查阅这篇小红马儿童会发布的****文章。

啰嗦了那么多，还有最后一条求同好的，最近一年迷上了烘焙，这些是我的拙作，请达人们多多交流指导。

下面咱们进入正题。自06年与SAP结缘开始，先后在甲方和Partner公司工作了很长一段时间，去年7月加入SAP成都研究院，成为SAP Cloud for Customer(C4C)开发团队的一员。与一直专注做标准产品开发的同事们不一样，由于身份的变化，这些年我在不同的SAP项目上的工作内容也有挺大的不同。

我特别喜欢用房子来给完全不了解SAP的朋友们解释我是做什么工作的。当一家公司要上一款信息化产品前，通常会先选型，就跟我们去买房一样，会根据自身的需求先圈定一些目标，比如选择心仪的品牌开发商，追求容积率低，绿化好的楼盘，或者是根据自己的预算去选择，客户也一样。SAP作为行业内知名龙头厂商，和其它竞争对手一起竞标，调研客户需求并推荐适合的商务套件。一旦客户选型完毕，就要进入到项目实施阶段了，相当于精装房交付但入住前需要有设计师进行硬装软装设计，再由施工团队完成装修工作，各大咨询公司的实施团队就在这个阶段粉墨登场，顾问会详细地调研需求绘制蓝图，等同于设计定稿，项目实施上线交付就是业主可以拎包入住的时候了。

从业主到装修公司到开发商一路走来，有趣的故事不少，以后有机会再跟大家唠唠。今天跟大家分享的内容是C4C中社交媒体集成(Social Media Integration)的部分。

在一个能自助服务就不选择人工介入的时代，社交媒体在现代人的生活中扮演了越来越重要的角色，大家不妨回忆一下自己每天刷微博微信的频率。目前 C4C系统已经实现了与Facebook/Twitter/Instagram/YouTube/WeChat等多种渠道和C4C Ticket服务场景的集成，另外还支持Custom Channel(客户自定义渠道)用于上述标准渠道之外的其它类型。

我们以Twitter为例，来探索一下社交媒体与C4C Ticket的集成。假设有这样一个业务场景：苹果公司在Twitter网站上有一个官方账号叫做Smart Apple，有一天客户Sherry的iPhone发生故障了，在Twitter上首次@Smart Apple发布了一条消息： "我的iPhone X坏了"。这条消息会自动被C4C抓取，首先为Sherry创建一条Business Partner主数据，再创建一个相应的Ticket。客服人员被分派这个Ticket之后，在C4C系统回复: "请提供您手机的序列号及具体的故障说明"，Sherry立即在Twitter上收到这条回复，并可以通过继续回复或者直接私信的方式进行后续交流。

下图是Twitter网站上Sherry的抱怨被成功抓取到C4C系统后生成对应的Ticket截图：

C4C客户人员可以在Ticket明细页面直接回复客户，

这条来自C4C系统的Ticket回复文本会出现在Twitter网站上，投诉问题的客户能直接在Twitter上收到问题处理的结果。

其实我的同事Jerry所在的SAP成都研究院CRM开发团队，早在2013年时就在SAP CRM On-Premises呼叫中心里实现了类似的功能，详情可以查看Jerry的文章：OAuth 2.0协议在SAP产品中的应用。

对于苹果公司而言，实现这样一个场景只需要在C4C系统中进行两步简单配置：一是为官方Twitter账号创建一个Social Media Channel; 二是创建一个Social Media Message extraction run, 其实就是SAP顾问朋友们熟悉的ABAP后台作业，关联第一步创建好的Channel，并指定执行的时间和频率, 用来定期从Twitter网站抓取数据。除此之外不需要任何额外的开发工作。

详细的配置：

Administrator -> Service and Social Settings，找到Social Media, 新建一个Social Media Channel，每一个Twitter账号对应一个Channel。

Consumer key和Consumer Secret是这个channel与Twitter应用进行交互的必要信息，在Twitter Developers页面可以查看:

http://dev.twitter.com/apps

点击“Connect with Channel'，Twitter登录界面将在一个新的窗口打开，使用Twitter账号进行权限验证，当看到成功提示之后，可以关闭该窗口回到C4C的页面。

关于OAuth2.0协议在Twitter账号和C4C渠道绑定中起到的作用，请参考Jerry的文章：

OAuth 2.0协议在SAP产品中的应用。

通过Administrator -> Service and Social Settings，找到Social Media, 新建一个Social Media Message Import Run，指定服务的Channel，并配置运行频率。大家可以把这个界面当成浏览器版本的SM37。

上述配置在系统中是怎么协同工作的呢？在介绍技术实现之前，我们需要先了解几个关键的Business Object。C4C Social Media有三剑客，SMAP、SMUP、SMA，三者相互调用，完成了Ticket与社交媒体的各种交互。以下BO结构仅为关键信息的示意，帮助大家了解BO之间是如何关联的。

SMAP，全称Social Media Activity Provider，对应的就是Social Media Channel。刚刚提到的Twitter官方账号和Channel的关联，以及关联配置时输入的设置信息都存储在下图所示的ACCESS INFO子节点中。

SMUP，全称Social Media User Profile, 每一个Twitter的个人账号对应一个SMUP BO实例。图示的BUPA子节点关联到一个BP 信息（例子中是Individual Customer），USER INFO子节点中存储的是其对应的社交媒体信息，对于Twitter和Facebook账号来说，只需要指定Channel Type和Communication ID即可，同一个BP的Twitter对应的SMUP只会有一个。微信稍有不同，后面再做解释。

SMA，全称Social Media Activity，也叫Social Media Message(消息)，每一次对话对应一条该BO的实例，包含了消息来源用户的SMUP信息、消息来源的Channel信息（SMAP）、消息内容(Interaction Content）等，根据一定的逻辑判断是否创建Ticket。以客服人员回复Ticket生成的SMA为例，Main Activity负责存储生成Ticket的消息，Parent Activity为客服回复所针对的消息，如果用户再次回复了客服，那么此条回复消息即为Child Activity。这样保证了一系列的会话和回复可以有序地串起来。

另外还有一个对象，是仅用于Inbound Message的，即我们前面说的第二步配置，在C4C里有个术语叫MDRO(Mass Data Run Object), 即C4C后台作业的技术实现。

消息交互分为两种场景。

一种是Inbound，即消息流从社交媒体导入C4C, 包括用户首次报Ticket, 用户对官方账号的回复, 用户私信官方账号等等。

每一个激活并设置了运行周期的Import Run都对应着一个ABAP后台作业，根据配置在其中的Channel ID对应的Twitter官方账号，调用Twitter API去抓取新生成的消息。得到消息列表之后，先查看该消息来源的Twitter账号是否在系统中有匹配的SMUP信息，如果有，取得该信息用于Activity的创建; 若没有，判断User Category为standard则创建一条Individual Customer并基于此创建一条SMUP，再进行Activity的创建。

创建Activity的同时，SMA的determination实现会根据消息的类型判断是否创建新的Ticket。若需要，则调用BADI进行创建。Ticket和Social Media 的关系是由Business Transaction Document Reference 关联起来的。

另一种场景是Outbound，即客服人员在C4C回复Ticket，回复内容会被推送到Twitter。

Outbound场景的另一个变式是客服在C4C里转发。

讨论完Twitter，我们再来看看大家更加熟悉的微信。微信与C4C Ticket的集成与Twitter/Facebook相比有着很大的差异。

首先，微信有一个独有的Agent Server(也称消息服务器，中间服务器等等)，需要额外的开发来完成与C4C的集成；

比如Jerry这篇文章 打通C/4HANA和S/4HANA的一个原型开发：智能服务创新案例 里展示过一张架构图，红色高亮部分就是Agent Server，作为终端用户手中的微信客户端和C4C系统交互的中间件。

其次信息推送的方式不同，Facebook/Twitter是被动地等待C4C来读取消息，而微信则是主动向C4C推送消息的，因此微信和C4C的集成，不需要定义Import Run这种后台作业。

与Twitter官方账号类似，每个微信公众号对应C4C系统里一个Social Media Provider。在创建SMUP的时候，由于每一个用户对于不同的公众号，OpenID都是不同的，因此还需要额外指定External Party ID，即关联到公众号的Provider，这样C4C在往微信推送消息的时候才能根据BP信息和Channel找到对应的SMUP，从而确定OpenID，把消息推送到正确的公众号去。

这里给大家解释一下微信OpenID的概念，它与微信ID和微信昵称到底有什么区别呢？

• 微信 ID: 相当于微信用户在微信这个APP的身份证号码，唯一且创建之后不可更改。你的朋友可以通过微信ID搜索到你。

• 微信昵称: 微信昵称是微信用户显示在朋友的联系人清单里的名字，可以多次更改。

• 微信 OpenID: 当一个微信用户关注了一个微信公众号之后，公众号可以获取到该用户对应的OpenID，对公众号来说，每个关注了该公众号的用户会通过一个唯一的ID来标识；对微信用户来说，他/她关注了多个不同的公众号，会对应多个不同的OpenID。

以下图为例，用户李晓刚同时关注了苹果的售前和售后公众号，会在SMUP中生成两条User Profile，对应两个不同的OpenID。当他通过售后公众号报了Ticket之后，C4C的客服回复该Ticket时，除了BP号和Channel Type是微信之外，还需要知道该Ticket是通过哪一个公众号在C4C系统生成的，这样才能找到正确的OpenID，从而准确回复给对应的微信用户。因此在生成SMUP时，除了记录OpenID之外，还需要记录公众号的信息, 即Channel ID，也就是C4C系统里配置的Social Media Provider ID，对应到现实里就是一个公众号。而Twitter和Facebook的账号，只需要在创建SMUP时指定Channel Type即可。

最后让我们来看看微信和C4C集成的效果。下图展示的是通过Jerry的另一篇文章 C4C和微信集成系列教程 和我的同事Li Sean在SAP社区上发表的博客里介绍的步骤开发而成的功能：

https://blogs.sap.com/2018/02/28/integration-of-wechat-and-c4c-service-ticket-on-html5-client/

客户在微信客户端提出一个产品故障报告：

通过上面介绍的集成场景，在C4C自动生成了一个Ticket：

C4C的客服人员被分配到这个Ticket后，在C4C里回复，告诉客户该故障已经在处理中了：

客户在自己的微信客户端上收到了C4C客服人员的回复：

以上就是我对C4C社交媒体集成这个话题的一些分享，如果大家有任何疑问或者希望进一步探讨，欢迎联系我们，感谢阅读。

更多阅读

• C4C和微信集成系列教程

• SAP成都研究院大卫哥：SAP C4C中国本地化之微信小程序集成

• SAP成都研究院飞机哥: SAP C4C中国本地化之微信聊天机器人的集成

• 打通C/4HANA和S/4HANA的一个原型开发：智能服务创新案例

• 一些SAP Partners能够通过二次开发实现打通C/4HANA和S/4HANA的方法介绍

• OAuth 2.0协议在SAP产品中的应用