十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
这周Jerry在长沙客户现场待了几天,感谢易总和彩亮的款待。终于有机会和关注这个公众号的一些CRM顾问们进行线下互动,感觉很不错。得知公众号里某些文章帮助顾问们解决了一些工作中的实际问题,我很高兴。感谢大家的支持,只要时间允许,这个公众号我会一直写下去。
成都创新互联公司专业为企业提供滨州网站建设、滨州做网站、滨州网站设计、滨州网站制作等企业网站建设、网页设计与制作、滨州企业网站模板建站服务,10余年滨州做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
和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中便可通过上图界面完成。
创建一个单位,用于定义产品价格:EA
用已创建的单位EA来定义一个类型为基于客户使用的计费元素,ID为APICall。以及一次性和按月收费元素ONETIME,RECURRING:
在计费元素定义好之后,接下来便可配置在创建和编辑报价单时可以编辑哪些价格元素,以及在产品包含的数量使用费用中编辑和隐藏哪些价格元素。
接下来还可在Business Configuration中配置用户授权以批准报价,触发报价中审批流程的参数,计费的延迟(计算的结算日期会延迟指定的天数,从而产生新的结算日期)等其他与业务流程相关的参数。
上图表示在US East Market下的报价单,若价格折扣大于等于20%则该报价单需要审批。
基础配置完成后,便可以创建主数据。首先到Customers Tile里维护客户信息。可以创建个人客户或者企业客户。下图创建一个企业客户,维护客户的地址、联系人信息,并且指定到之前创建的Market A1-US East:
Products 维护产品主数据
客户创建完成后,接着维护产品信息,可以创建订阅型产品或者组合式产品。如图创建一个订阅式产品Mail_service,指定Market到US East,并创建对应的价格信息RatePlans。指定产品的账单生成日期于每月订阅日期,订阅该产品一次性费用为988美元,按月费用为50美元,同时产品包含1000次APICall,每超过100次收费20美元。
主数据创建成功后,便可以在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 Tile查看订单状态,是否生成了对应的订阅订单(Subscription)。图中可看到Subscription创建完成。
在Subscriptions Tile中查看生成的订单:
在创建报价单时,由于把订阅开始日期定在过去,接下来便可以去查看生成的账单包含了一次性以及按月费用:
客户对该产品的使用数据可在Usage Data中维护,倘若客户SUNNY使用了1200次APICall, 维护使用数据如下图:
再次查看账单数据,可以看到新的账单项生成。产品Mail_service定义的包含APICall为1000次,每额外的100次收费20美元,客户的usage为1200次,收费40美元:
由此,一个完整的由报价单到根据产品使用的账单生成的流程便完成了。
要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码: