传统的扩展方式，即In-App增强方式，Hybris开发顾问通过Extensions的方式进行二次开发，生成的Custom Extensions同Hybris标准的Extensions一起参加构建，构建结束后新功能方可使用。在构架过程中，Hybris实例暂时无法访问(down time)。这种方式允许Hybris顾问以较高的灵活度在Custom Extensions里编写代码来实现增强需求。

借助SAP Cloud Platform Extension Factory实现的Side-by-side增强，不需要修改Hybris实例(图二虽然标注的是Commerce Cloud，但对Hybris Commerce On-Premises版本仍然适用)本身的代码，而只需在Extension Factory上编写针对Hybris标准程序发布事件的响应处理函数。例如客户需求是当Hybris Storefront上有新用户注册，或者新订单生成时，实现一段自定义逻辑——这类事件驱动的增强需求，采用Extension Factory增强，开发效率较In-App增强更高，实现更轻量，但前提是Hybris标准应用在需要被增强的业务流程上对事件发布有完善的支持。

grant_type为client_credentials和password二者的区别

最近工作中需要使用到oauth，注意到oauth客户端的grant_type值可以指定为client_credentials和password两种，很好奇所以网上搜索了一下，发现stackoverflow上一个帖子：
https://stackoverflow.com/questions/34842895/difference-between-grant-type-client-credentials-and-grant-type-password-in-auth

这位网友注意到一个有趣的点：

grant_type=client_credentials时，请求的响应中不包含refresh_token:

而grant_type为password则包含refresh_token:

什么时候用client_credentials(客户端模式)作为grant_type?

下面这个网站有介绍：https://www.poken.com/api/authentication/oauth2/
例如Account creation这个API，从业务上说我们期望它可以通过一个未认证过的用户调用，因为在Account创建之前，不存在authenticated user，这种场景下用grant_type=credentails比较合适。

grant_type=password的情况下，请求access token时，需要在HTTP请求里加上client_id和client_secret两个参数。

grant_type = password

客户端需要用户的用户名和密码，然后将客户端自己的client_id和client_secret发送给认证服务器，换取access token. 适用于受信客户端，比如一种服务对应的移动客户端。

grant_type=client_credentials

帖子里举了一个例子，比如实现一个后台作业，调用API完成一些维护工作，这里面不涉及到采集终端用户的用户名和密码，所以用client_credentials比较合适，这种情况下拿Access Token只需要client_id和client_secret即可，不需要用user_id和password了。