金庸和古龙，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的原创技术文章，请关注公众号"汪子熙".