搜尋 SAP成都研究院廖婧：SAP C4C社交媒體整合概述

曾經有朋友在知乎上向我提問，諮詢在SAP成都研究院工作的體驗。

當時，我的回答提到一點， SAP注重工作與生活的平衡 ，這也是SAP中國官網強調的一點。

具體到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產品中的應用