SAP HANA 获取已登陆用户的详细信息

我们在浏览器上访问我们在 SAP HANA 上面部署的应用的时候,总会先跳转到一个 SAP ID Service 的页面并要求我们注册和登陆。在成功登陆 ID Service 后,这个用户身份就会作为我们在 Application 上的用户。

这是由于 SAP HANA Cloud Platform 采用了 single sign-on (SSO) 和身份绑定的方式,使开发者能无缝的将身份管理设施集成到 HANA Cloud Application 上。
这样做的好处是开发者无需开发单独的用户管理系统,用户信息由 identity providers (IdP) 提供并统一进行管理。
同时对于用户来说,使用统一的身份进行登陆,可以省去很多个人信息注册和更新的麻烦,并保证整个 HANA 平台上的应用间的身份信息一致。
这种做法应用开发者不需要再本地存储用户验证数据,能很好的避免信息丢失或泄露,对用户更有保障。

SAP-Cloud-IdP

当我们需要获取用户的信息来做相关的应用开发时(大部分时候是需要的),这种方式就给我们带来了极大的便利。我们只需要从 IdP 提供的接口就能很方便的获取到用户的信息。

SAP HANA 默认的 IdP 就是前面提到的 SAP ID Service,这是每个 HANA Application 的默认 IdP,维护了一整套的 SAP 体系内的用户信息。无论你是内部员工,还是外部客户,或者是 SCN 注册用户,都会由这个 Service 来进行维护。

SAP-ID-Service
Continue Reading…

SAP HANA 增量合并操作 (Delta Merge Operation)

我们都知道, SAP HANA 的数据更新方式是采用增量合并操作(Delta Merge Operation)的方式,原始数据在 Main 区域,新增加的数据在一个 Delta 区域,通过不断合并 Main 和 Delta 形成新的 Main,比普通的修改方式在性能上有着很大的优势。
今天看了一下整个增量合并操作中数据的读写和合并过程,感觉还是蛮有意思的。对很多应用场景下的数据增删修改合并操作有着很好的借鉴意义。

我们先来看一幅图:

sap-hana-delta-merge

Continue Reading…

SAP HANA ODATA 跨域访问

在 SAP HANA 中,我们通过开源的 ODATA Java 实现 — Apache Olingo,构建了一个 Java Application 来实现 ODATA。ODATA Service 的地址是访问
ApplicationPath/*.svc
当你访问这个地址时,会自动调用同名的 servlet 进行相关的操作。

当我们访问这个地址时,一切还是正常的。但当我们在构建的 HTML5 Application 中为了使用该 ODATA Service 中的数据,将该地址作为 ODATA Service 地址传入的时候,访问出现了
400 Bad Request

odata-400
出现400无效请求的原因是因为 ODATA Service 和 HTML5 Application 不在同一个域中,为了保护数据,ODATA 对来自其他域的请求做了限制。

解决的方法是在 HANA 中设置一个 Destination 作跳转:
Continue Reading…