金庸和古龍，Netweaver和微服務，以及SAP Hybris Revenue Cloud

這周Jerry在長沙客戶現場待了幾天，感謝易總和彩亮的款待。終於有機會和關注這個公衆號的一些CRM顧問們進行線下互動，感受很不錯。得知公衆號裏某些文章幫助顧問們解決了一些工做中的實際問題，我很高興。感謝你們的支持，只要時間容許，這個公衆號我會一直寫下去。

和CRM顧問們中午吃飯時聊到了SAP一些新的雲產品採用了微服務架構開發，所以我寫了這篇文章。

若是要找金庸小說裏幫助Jerry提升編程水平最有用的一句話，無疑是：重劍無鋒，大巧不工。

楊過被郭芙斬斷一臂後，之前掌握的編程語言，哦不，之前掌握的武功均無從施展。後來楊過無心發現一本編程祕籍，上書：重劍無鋒，大巧不工。

• • *

楊過喃喃念着「重劍無鋒，大巧不工」八字，心中似有所悟，但想世間劍術，不論哪一門哪一派的變化如何不一樣，總以輕靈迅疾爲尚，這柄重劍不知怎生使法，想懷昔賢，不由神馳久之。

春去秋來，歲月如流，楊過日日在海潮之中練劍，日夕如是，寒暑不間。木劍擊刺之聲越練越響，到後來竟有轟轟之聲，響了數月，劍聲卻漸漸輕了，終於寂然無聲。又練數月，劍聲復又漸響，自此從輕而響，從晌轉輕，反覆七次，終於欲輕則輕，欲響則響，練到這地步時，屈指算來在海邊已有六年了。

這時候楊過手仗木劍，在海潮中迎波擊刺，劍上所發勁風己可與撲面巨浪相拒，神鵰縱然力道驚人，也已擋不住他木劍的三招兩式，這時他方體會到劍魔獨孤求敗暮年的心境：「以此劍術，天下復有誰能與抗手？無怪獨孤前輩自傷寂寞，埋劍窮谷。」

• • *

楊過的重劍研習之路對Jerry編程有什麼啓發？

當今IT圈子裏，新技術新名詞，甚至新的編程語言層出不窮。一個程序猿，能夠選擇不停地學習，追逐這些新事物，就像楊過前後學了蛤蟆功，天羅地網式，玉女劍法，全真劍法，打狗棒法，玉簫劍法，彈指神通等。也能夠選擇靜下心來，好好打磨程序員須要掌握的最基本技能。

楊過花了六年的時間在海潮中提高本身的內功，再重出江湖後面對之前同一級別的對手都能作到秒殺。Jerry也幻想有一天能像楊過那樣，秒殺本身遇到的bug，而不是像如今這樣，一個bug苦苦debug幾小時。Jerry還在修煉的路上：Jerry的ABAP, Java和JavaScript亂燉。

金庸對玄鐵重劍的描寫：「那劍黑黝黝的毫無異狀，倒是沉重之極，三尺多長的一把劍，重量竟自不下七八十斤，比之戰陣上最沉重的金刀大就尤重數倍。兩邊劍鋒都是鈍口，劍尖更圓圓的似是個半球。楊過看劍下的石刻時，見兩行小字道：重劍無鋒，大巧不工。四十歲前恃之橫行天下。」

重劍無鋒，大巧不工 這八個字的字面含義：表面上看來越愚笨越平凡的東西，越可能蘊涵着精巧的極致。這難道不是在說SAP基於Netweaver開發的那些傳統產品？

拿S/4HANA爲例，裏面包含數以萬計的數據庫表，任何一張單獨拿出來都貌似平平無奇。這一張張不起眼的表，就像一部德國戰車上一個個精巧的零件，將SAP三十多年企業管理領域深耕的功力體現到了極致。

並非每一個劍客都能運用楊過的玄鐵重劍。一樣的，基於Netweaver的應用開發也須要一些門檻。SAP傳統的產品本質上是一個monolithic系統，底層數據庫的內容經過API暴露出來後，並不可以直接給UI消費。UI和API層之間每每還有其餘的中間層存在，換言之，應用開發人員沒法真正作到「專一於應用邏輯自己的編寫」，仍需花費精力掌握一些和業務不太相關的技術。

例如CRM應用開發人員須要熟悉如何將API返回的數據進行格式轉換並存儲到Genil容器中。S/4HANA開發人員在BOPF裏實現應用邏輯，得須要知道如何使用/BOBF/IF_FRW_READ和/BOBF/IF_FRW_MODIFY。SRM開發人員除了會ABAP Webdynpro以外，還得掌握FPM的用法。不過好消息是，若是您的內功深厚，那麼只要掌握其中一門，再接觸其餘的也能很快融會貫通。

另外一位大師古龍，其武學設定和金庸大相徑庭。翻開任何一篇古龍的做品，使用關鍵字」內功」搜索，幾乎都不會獲得結果。在古龍的武俠世界裏，「快」就是王道。好比做品《小李飛刀》裏，對李尋歡的武功招式沒有任何正面描寫，而是用側面描寫的方式突出其飛刀之快：

• • *

伊哭瞪着李尋歡，獰笑道：「你還有什麼話說？」

李尋歡望着他青光閃閃的青魔手，緩緩道：「只有一句話。」

伊哭道：「什麼話？你說！」

李尋歡嘆了口氣，道：「你何須來送死？」

他的手突然揮出！

刀光一閃，伊哭已凌空側翻了出去。

雪地上已多了串鮮血！

再看伊哭的身影已遠在數丈外，嘶聲道：「李尋歡，你記着，我……」

說到這裏，他聲音忽然停頓。

寒風如刀，天地肅殺雪地上變得死通常靜寂。

• • *

SAP不少雲產品，例如SAP Hybris Revenue Cloud，基於微服務架構開發而成。同SAP傳統的基於Netweaver的產品相比，這些雲產品的應用邏輯開發一大特色就是：開發速度快。藉助SpringBoot和CloudFoundry的命令行工具CLI，開發人員能夠真正專一於微服務應用邏輯的編寫，而後將微服務快速部署到雲平臺上。UI能夠用輕量級的AJAX調用來消費這些微服務。

好比Revenue Cloud的客戶主數據列表，就是經過部署在revcloud.XXX.eu10.revenue.cloud.sap上的一個微服務返回的。該微服務在UI5的代碼裏經過輕量級的AJAX調用進行消費。

基於Netweaver和基於微服務架構的兩種開發方式，很難評價哪一種更好，就像沒法評價金庸和古龍誰的做品更優秀同樣。Netweaver做爲SAP傳統應用的開發和運行平臺，經過30多年歲月洗禮被證實是適合S/4HANA這種超大規模的複雜系統開發。而像SAP Hybris Revenue Cloud這種基於微服務架構的新一代雲產品，體現了SAP在雲時代緊跟行業發展步伐的決心。

下面邀請個人同事，SAP成都研究院Revenue Cloud開發團隊的陳文心(Chen Vicky)給你們簡單介紹Revenue Cloud目前已經發布的一些功能。

Vicky 2016年畢業後加入SAP成都研究院，90後青春靚麗程序媛一枚。我從她的朋友圈盜了一張圖：

SAP Hybris Revenue Cloud功能概述

你們好，我是陳文心，如今工做於SAP成都研究院Revenue Cloud開發團隊。大學實習時作的是SAP ERP ABAP開發，進入SAP後與Hybris Renenue Cloud 一塊兒發展，走過了兩個春夏秋冬。目前工做使用的技術棧是Java，JavaScript和SAP UI5。做爲一名程序員，追求質量是永恆不變的真理。從代碼的正確性，可擴展性到交付流程的完整性，我還須要向SAP成都研究院其餘資深開發人員學習。

生活中喜歡讀書，聽歌和彈古箏。 最愛的一本書是羅曼羅蘭的《約翰克里斯多夫》，聽着歌寫代碼，靈感更能迸發。十年磨一劍，彈琴如此，寫代碼依然如此，有追求和付出纔會有更好的結果。

下面是Revenue Cloud已經發布的功能概述，若是有朋友對這個雲產品一無所知，但願看了這篇文章能有一些基本的瞭解。

SAP Hybris Revenue Cloud 是一種新的基於微服務的雲解決方案，可以幫助企業在敏捷和可擴展的環境中快速部署高效的銷售流程，從而充分利用其餘SAP On-Premise和雲產品。

SAP Hybris Revenue Cloud由三個主要功能組成：

• 訂閱式訂單生成
• 訂閱式訂單管理
• 訂閱式訂單計費（包括使用費和一次性費用）

登錄SAP Hybris Revenue Cloud 進入主頁面能夠看到業務流和主數據的配置：

設想這個場景:使用Revenue Cloud的企業A有一個客戶SUNNY,該客戶須要訂閱A公司的Email service用於自身產品發送郵件的需求。A公司的Email service屬於訂閱型產品，按使用收費。那麼A公司從建立客戶到客戶帳單生成這一端對端的流程，在SAP Hybris Revenue Cloud中即可經過上圖界面完成。

Business Configuration 業務相關基礎配置

首先進入Business Configuration配置產品流程須要的基礎元素，建立一個ID 爲A1的market：

建立一個單位，用於定義產品價格：EA

用已建立的單位EA來定義一個類型爲基於客戶使用的計費元素，ID爲APICall。以及一次性和按月收費元素ONETIME,RECURRING:

在計費元素定義好以後，接下來即可配置在建立和編輯報價單時能夠編輯哪些價格元素，以及在產品包含的數量使用費用中編輯和隱藏哪些價格元素。

接下來還可在Business Configuration中配置用戶受權以批准報價，觸發報價中審批流程的參數，計費的延遲（計算的結算日期會延遲指定的天數，從而產生新的結算日期）等其餘與業務流程相關的參數。

上圖表示在US East Market下的報價單，若價格折扣大於等於20%則該報價單須要審批。

Customers 維護客戶主數據

基礎配置完成後，即可以建立主數據。首先到Customers Tile裏維護客戶信息。能夠建立我的客戶或者企業客戶。下圖建立一個企業客戶，維護客戶的地址、聯繫人信息，而且指定到以前建立的Market A1-US East：

Products 維護產品主數據

客戶建立完成後，接着維護產品信息，能夠建立訂閱型產品或者組合式產品。如圖建立一個訂閱式產品Mail_service,指定Market到US East,並建立對應的價格信息RatePlans。指定產品的帳單生成日期於每個月訂閱日期，訂閱該產品一次性費用爲988美圓，按月費用爲50美圓，同時產品包含1000次APICall，每超過100次收費20美圓。

Quotes 建立報價單

主數據建立成功後，即可以在US East Market中對客戶SUNNY建立Mail_Service的報價單，並給產品的一次性費用25%的折扣，同時指定報價單的有效日期以及產品的訂閱有效起始日期。

點擊Release發佈報價單，因爲以前在Business Configuration中對US East Market設置的最大折扣爲20%，因此該報價單須要審批。點擊「Send for Approval」將報價單送去請求審批。 

在Business Configuration中對US East Market 建立的approval list中的員工即可贊成或拒絕等待審批的訂單。

待報價單審批經過後，即可發送給客戶，待客戶接受報價單後即可轉到Order生成訂閱訂單：

Orders 查看訂單處理狀態

接着即可到Orders Tile查看訂單狀態，是否生成了對應的訂閱訂單(Subscription)。圖中可看到Subscription建立完成。

Subscriptions 查看訂閱訂單

在Subscriptions Tile中查看生成的訂單：

Billing Data 查看帳單數據

在建立報價單時，因爲把訂閱開始日期定在過去，接下來即可以去查看生成的帳單包含了一次性以及按月費用：

Usage Data 維護客戶使用數據

客戶對該產品的使用數據可在Usage Data中維護，假若客戶SUNNY使用了1200次APICall, 維護使用數據以下圖：

再次查看帳單數據，能夠看到新的帳單項生成。產品Mail_service定義的包含APICall爲1000次，每額外的100次收費20美圓，客戶的usage爲1200次，收費40美圓：

由此，一個完整的由報價單到根據產品使用的帳單生成的流程便完成了。

要獲取更多Jerry的原創技術文章，請關注公衆號"汪子熙".