金庸和古龍，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美元：

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