SAP Subscription Billing是SAP推出的用于订阅关系(Subscription)管理的一款SaaS产品。通常来说,任意一个标准产品都不可能满足所有客户的实际需求;因此,随着客户越来越多,产品的可扩展性显着尤其重要。这篇文章简单介绍一下Subscription Billing的可扩展性功能。
1
总体来讲,Subscription Billing的可扩展性可分为两个方面:字段扩展和流程扩展。
字段扩展,通过Custom References实现。举个例子,销售代表可以把Customer的身份证号码(非标准字段)维护在Custom References里面,在后面查询的时候也就可以方便地基于身份证号查询;在SAP Subscription Billing和SAP CPQ集成的场景,CPQ作为一个leading system,销售代表先是在CPQ中创建一个Quote,Quote确认之后系统自动创建一个Subscription,这时,如果把Quote Number维护在Subscription的Custom References中,就可以方便的通过Quote Number查到对应的Subscription。
流程扩展,就是在一个标准流程执行过程中提供一些可扩展点,客户可以通过这些扩展点实现一些自定义逻辑。在Subscription Billing中,流程扩展的主要应用场景是:其它系统通过Previsioning Request和Subscription Billing集成,当创建了一个Previsioning Request之后,Orchestrator组件会根据提前配置好的Orchestration Configuration来创建Subscription;在创建的流程中,客户在Orchestration Configuration中定义的一些扩展点也会被触发。目前,支持的扩展点有两个:提供technical resource id和执行自定义的事件。在Orchestration Configuration中,除了可以定义多个扩展点之外,还可以定义每个扩展点的执行位置。
如下是一个简单的Orchestration Configuration配置例子:
上面的配置定义了两个扩展点,一个是提供technical resource id,在创建Subscription之前执行;另外一个是执行custom activity,在创建Subscription成功之后执行。
基于上面的配置,整个创建流程如下:创建一个Previsioning Request之后,Orchestrator组件发现客户的配置是客户需要自己提供technical resource id,于是暂停流程执行并且触发一个technical-resources-required的事件 -> (执行第一个扩展点)客户的一个service轮询这个事件(GET /events/technical-resources-required),生成对应的technical resource id,然后把id返回给orchestror组件(通过POST /events) -> 紧接着,Orchestrator继续执行,创建Subscription,如果创建成功,则执行最后一步,发现最后一步客户配置的是要执行Custom Activity,于是又暂停执行,触发一个activity-required事件 -> (执行第二个扩展点)客户另一个service轮询这个事件(GET /events/activity-required),收到这个事件之后,执行相应的逻辑操作(比如发送创建Subscription成功的通知邮件),执行完成之后,confirm完成(POST /events) -> Orchestrator继续执行,整个流程执行完毕。
关于SAP Subscription Billing可扩展性的具体细节,大家可以参考SAP官方help document。
2
关于上面介绍的流程扩展,下面是一些思考:
3
关于字段扩展和流程扩展,在编程语言层面也同样需要考虑。
References