金庸和古龙，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的原创技术文章，请关注公众号"汪子熙"或者扫描下面二维码:
