Thursday, August 9, 2018

SAP HANA Extended Application Services (SAP HANA XS) flavors

HANA has built-in an application server for native development in the SAP HANA environment. There are actually two flavors application servers. I depict here the two and mention some differences. 

HANA native application development resides on the XS server (or also called as XS Engine or just XS). The XS is a small footprint application server including: web server and basis for an application development environment.  The XS is installed on the same hardware as SAP HANA. It does extend the SAP HANA database. It makes a platform out of it.


XSC - SAP HANA XS classic, lightweight application server includes web based HTTP and OData services. It can consume HANA database artifacts (e.g. calculation views) and it has built in support for the SAP Fiori UI. Also supports transactional services based on core data services (CDS). It uses database permissions, there are DB users in HANA itself. It was introduced in SAP HANA SPS 05 (around year 2012). 

Programming model: OData REST services is generated from any existing SAP HANA Table or View. All metadata and source codes (XS server-side JavaScript (XSJS)) for XS Classic app are stored in the SAP HANA repository.


XSA - SAP HANA XS Advanced is a new application server for native development in the SAP HANA environment. It supersedes SAP HANA XS. It is decoupled from HANA, are not necessary users in HANA DB. XSA started to be delivered SAP HANA SPS 11 (around year 2015).

Programming model: UI rendering and other front end processing is normally done in web browser using HTML5 and client-side JavaScript. Application logic, business logic, calculations, and data processing talks place in HANA DB by using SQL, SQLScript procedures, Calculation Engine (CE) functions. Means data processing is performed in database - close to the data. Three runtimes currently supported: 

XSJS - same as in XSC
Node.js – to support asynchronous web programming model, to leverage node.js’s ecosystem as there are many open source nodejs modules
Java – as there is a huge number of popular Java frameworks out there


More information:
SAP HANA SPS 11 new developer features xs advanced

Tuesday, August 7, 2018

SapMachine

It is OpenJDK implementation released and supported by SAP company. It is intended to enable SAP customers who runs OpenJDK in their environments. As they also use it productevelly SAP needs a platform to support their customers. It is technically fork from OpenJDK project but as SAP needs to react quickly on customer issues they rather providing “their own” OpenJDK implementation as for regular OpenJDK being open-source software the changes are not going on that fast as SAP would need. Another purpose of the SapMachine is used to showcasing and adding a new features of SAP’s proprietary Java Virtual Machine (SAP JVM) – also because they want to make it quicker than regular OpenJDK.

Related links:
What version of JAVA platform does SAP support?

SAP JVM online docu
1278274 - SAP JVM Restrictions (FAQ)
 

Unified Connectivity (UCon) framework part 2

I wrote about the UCon already few years ago see here: NetWeaver Unified Connectivity (UCON).
This post has refreshed info on the topic.

I introduced whitening / blacking (list) features of SAP in my older blog spot: White / Black Lists. In SAP terminology a securing of some of SAP objects is also called in as Unified Connectivity (UCON). It was introduced on NetWeaver platform in version 74. Very high level speaking the UCON is all about logging and blocking. By using the UCON only those of remote enabled function modules (RFM or BAPI) that are used in deployed scenarios are allowed to be executed. Execution of rest of them is forbidden and thus the NetWeaver system is secured on server side because possible attack to the system is reduced. 

To identify which RFMs are to be exposed and which are to blocked there are three phase process and toolset provided by the UCON. 

First of all, a system parameter ucon/rfc/active needs to be set in tcode RZ11 – system profile parameters. 

In 1st phase (Logging) you need to identify objects that ae accessed from outside systems. Here a tool called ”Phase Tool Unified Connectivity” (tcode UCONPHTL, prog UCON_PHASE_TOOL) is used. Also CCMS contains SAP Unified Connectivity Monitor Templates that are supporting the tool. 

Now in 2nd phase (Evaluation) it checks whether objects are not interrupting deployed business scenarios by being blocked.  Also tcode UCONPHTL is used in here.

And finally in 3rd phase (Activation) it needs to be confirmed that UCON checks will become effective. 

There is also possibility to override blocking settings of some RFM delivered by SAP. This is of course at your own risk. The ABAP program RS_RFC_BLACKLIST_CUSTOM can be used for that. By giving the RFM name to the program you can see what were original settings of the RFM. No need to add that all changes to the settings are logged. So by this way blacklisted RFM can be unblocked. The settings done by the program are transportable.

More information: