SAP Community - SAP Java Connector (JCo)

SAP UI和Salesforce UI开发漫谈

2018-06-03T16:20:40+02:00

SAP UI

Salesforce UI

Apex

Lightning Experience

Aura Framework

Lightning Component Framework

Visualforce

SAP UI

SAP GUI + Dynpro

用SAP GUI + Dynpro 开发应用的UI界面仿佛是石器时代的事情了。据我所知，至少在SAP成都研究院已经没有团队仍旧使用这种古老的技术来开发UI了。虽然S/4HANA的后台还有大量事务码可供终端用户使用，但是，借助SAP Internet Transaction Server(ITS)，这些基于SAP GUI的事务码可以直接运行在浏览器端，并且具有Fiori应用的外观。

也就是说，如果您的S/4HANA On Premise客户需要一些新的UI, 除了常规的UI5开发方式之外，从技术上说，您完全可以仍然用SAP GUI开发一个Dynpro Screen, 然后封装成一个事务码，最后把这个事务码分配到S/4HANA Fiori launchpad的某个tile上。具体做法可以参考我的博客：Open your SAP GUI transaction in Fiori launchpad

用浏览器访问SAP GUI 事务码SE80的效果如下：

实际上，S/4HANA的很多标准应用也采用了这种做法。以物料主数据管理应用为例，S/4HANA既存在采用这种“障眼法”打造而成的伪Fiori应用（下图标注了事务码的3个tile），也存在下文要介绍的根正苗红的原生Fiori应用（下图蓝色tile所示）。

Web Dynpro

从实现语言上分为ABAP Web Dynpro和Java Web Dynpro。据我所知基于ABAP Web Dynpro开发的SAP标准应用比Java Web Dynpro多得多, 比如SAP SRM的标准UI就基于ABAP Web Dynpro。另外有很多属于SAP_BASIS software component的应用或框架，其UI也是使用ABAP Web Dynpro开发的，最著名的莫过于BRF(Business Rule Framework) 。

作为Netweaver ABAP栈的一部分，BRF和其升级版BRF+在SAP许多产品里都发挥了重要作用。典型的例子有SAP Solution Manager的Incident Management和SAP Cloud for Customer的Service Request应用场景里的Support Team Determination功能。通过BRF我们可以配置一系列规则(rule)，这些规则基于Incident的component，system id, client id和priority等字段。BRF能够根据用户配置的这些规则，自动决定出哪个团队应该处理该Incident / Service Request。

再有就是SAP Document Builder，一款复杂文档生成的解决方案。文档管理员负责配置符合实际业务中使用文档外观及格式的文档元素(element), 这些通过Word编辑的文档元素是最终生成文档的组成部分。用户访问ABAP Web Dynpro UI，填写一些关键字段，最后一键生成PDF，Word，HTML或者XML格式的文档。

该技术尤其适用于部分国内客户，这些客户认为SAP标准UI导出而成的文档格式和客户平日使用的纸质文档（比如销售合同）的外观相去甚远。通过Document Builder，客户可以用Word设计符合自己格式和外观要求的文档元素作为模板然后上传到系统里，基于这些模板生成最终文档。

SAP Document Builder的ABAP Web Dynpro UI：

此外，ABAP Web Dynpro上手快，学习曲线相对平缓，具有接近所见即所得的UI编辑方式。作为一个MVC框架，ABAP Web Dynpro不需要像CRM WebClient UI那样必须开发一个真正意义上的Business Object(以下简称为BO)作为模型，而是可以直接在controller里面调用底层API。这种简单快捷的开发方式深受Partner的欢迎。在我支持过的每一个On Premise项目的二次开发里几乎都能看到ABAP Web Dynpro的身影。

尽管ABAP Web Dynpro有这么多优点，但并不意味着它是一个万能的解决方案。因为无法很好的适配移动设备，在Fiori诞生之后，ABAP Web Dynpro逐渐退出UI开发的历史舞台了。

需要提醒的一点:

如果一个SAP标准产品的UI不是使用ABAP Web Dynpro开发的，那么在您决定使用这个技术进行二次开发之前，请慎重考虑，因为您很可能会遇到这些坑：

后退按钮的处理

数据丢失的检测和处理

会话处理

对UI可配置性(configurability)的支持

消息显示区域的处理

对底层API不恰当的调用

这些坑都是我以前支持国内客户项目时，发现大量ABAP Web Dynpro和CRM WebClient混合使用造成的。关于这些坑的更多细节，请参考我的博客: Issue lists of using ABAP Webdynpro in CRM UI.

BSP/CRM WebClient UI

SAP BSP是一项神奇而重要的技术。神奇，是因为它历史实在太悠久了，据我所知从上世纪90年代年起一直服役至今。而它重要的一面，暂时卖个关子。

BSP和JSP的原理一致，能直接在前端HTML页面里通过<%和%>嵌入ABAP代码。

运行时这些ABAP代码在服务器端执行，然后被合并到页面源代码中去，最后服务器端将页面源代码发送给浏览器，显示给用户。

下图是一个BSP应用的例子。BSP的HTML里仍然能触发一些事件，但是这些事件的响应函数不是JavaScript函数，而是由ABAP实现的代码片段，即下图左边的On开头的一系列事件处理逻辑。

从上面的界面也能看出，BSP应用缺乏MVC支持，并且仅能在其框架支持的6个事件响应位置进行ABAP编程。用BSP开发一些小工具还行，如果拿来开发企业级应用则显得有些力不从心。正因为BSP的这个缺陷, CRM WebClient UI 才有了用武之地。

CRM WebClient UI应用本质上也是一个BSP应用，同传统的BSP开发事务码SE80不同，CRM WebClient UI有一个新的开发事务码，该开发工具提供了使用BO作为MVC中模型层的原生支持，即开发人员可以在开发工具里将BO某个字段绑定到UI某个字段上。

WebClient UI和下面将要介绍的SAP UI5一样，也包含了很多开箱即用的标准控件，只不过我们一般不用控件这个术语，而称为元素(Element)。应用开发人员只需要使用这些标准元素，就能快速开发出高质量的UI界面。

举个例子，下图是一个典型的使用WebClient UI实现的搜索页面，第2行和第3行声明了SAP标准元素库thtmlb和chtmlb的引用，然后在第11行使用了thtmlb库里的元素searchFrame。有SAP UI5开发经验的朋友可以把这种做法类别成在UI5的XML view里使用SAP标准的UI5控件，原理是相同的。

短短29行代码，就绘制出了如下图的搜索界面：不仅支持通过下拉菜单更换搜索条件，也支持通过带有+和-的圆形按钮添加或者删除搜索条件。

如此一来，应用程序开发人员无需再去编写原生的HTML代码和CSS。在运行时期，searchFrame元素对应的Render类会负责生成原生的HTML代码。

关于WebClient UI更多开发细节，请参考我的公众号文章Jerry的WebClient UI 42篇原创文章合集。

此外，CRM WebClient UI和ABAP Webdynpro相比，多了下图中红色方框所示的Business Object Layer和Generic Interaction Layer，有的朋友可能认为这两层会带来一些额外的运行时开销(runtime overhead),导致WebClient UI的性能不如ABAP Web Dynpro。

关于这个运行时额外开销的话题，我曾经做过评测，结果证明：假设用WebClient UI和ABAP Web Dynpro实现同样的需求，WebClient UI引入BOL和GenIL层带来的运行时开销并不会导致其性能比ABAP Web Dynpro相差太多。底层API逻辑越复杂，这个运行时开销越可以忽略不计。

下图就是我分别使用Social Post，Sales Order和Product三个应用测试出来的BOL和GenIL造成的运行时开销明细。关于我做的这个性能评测的更多细节，请参考我的博客

Webclient UI vs ABAP webdynpro: performance loss in BOL / Genil Layer discussion

SAP UI5/Fiori

这对术语经常伴随着彼此同时出现，有的朋友对二者的区别和联系搞得不是太清楚。Fiori是SAP官方的设计语言，代表一种UI的设计风格，我的同事周帅在他的微信文章 SAP成都C4C小李探花：浅谈Fiori Design Guidelines 里对SAP Fiori有着详细介绍。而SAP UI5是一种UI开发技术, 一个基于jQuery的UI开发框架和UI控件库。

目前S/4HANA, SAP Cloud for Customer, SAP Engagement Center, SAP Revenue Cloud这些产品的UI都基于SAP UI5。

为什么我前面介绍BSP时说这项技术如此重要呢？SAP的旗舰产品S/4HANA, 其Fiori应用仍是以BSP的方式存储在Netweaver上。

比如S/4HANA物料主数据管理的Fiori应用，其BSP应用名称：md_prod_mas_s1

该BSP应用在ABAP后台打开如下所示：

开发人员可以用WebIDE, Eclipse, Webstorm，Atom, Sublime Text或任何喜欢的其他IDE/编辑器进行SAP UI5开发。开发完成后，这些UI5应用一旦部署到Netweaver，SAP框架会自动创建一个BSP应用，存储该UI5应用的全部内容。关于更多Fiori应用的部署细节，请参考我的公众号文章 SAP Fiori应用的三种部署方式。

SAP UI5支持不同的view类型，最常用的是xml view和js view。对于xml view，在里面声明要使用哪些UI5控件。

在运行时，xml view被加载，内容被UI5框架的XMLTemplateProcessor解析成一颗DOM树，树上的每个叶节点对应xml view中一个UI5控件的声明。然后深度遍历这颗树，创建UI5控件运行时实例。因为是深度遍历，所以您能在下图调用栈里观察到很多handleChildren和createRegularControls的递归调用。

同xml view相比，js view里控件的实例化不是由XMLTemplateProcessor完成，而是开发人员在JavaScript代码里自行实现。

每个UI5控件都有一个对应的渲染器(renderer), 负责在运行时根据实例包含的各项属性渲染出对应的HTML原生代码。

然而有的S/4HANA Fiori应用，如果您按照我这篇文章 Jerry和您聊聊Chrome开发者工具介绍的方法，用Chrome开发者工具打开它的实现，会发现这个应用既没有xml view，也没有js和其他类型的view。那么，我们看到的Fiori UI到底是怎么画出来的呢？

举个例子，如果您按照我这篇博客的步骤，您可以在几分钟内，构造出一个支持Service Order增删改查的Fiori应用出来，并且不需要写一行JavaScript代码。

Create a CRM Service Order Fiori application within a couple of minutes

奥妙就在于这里使用了一个叫做Smart Template的Fiori框架。使用这个框架，界面布局信息不再维护于xml或者js view里，而是定义在CDS view内。

下图是我博客里提到的Service Order应用使用到的某个CDS view在ABAP Studio里的显示。可以观察到有很多annotation(注解), 其中名称以@UI开头的注解定义了一些元数据，描述了被注解的字段出现在Fiori UI上的具体位置。

@UI.lineItem: 以一个column的外观出现在UI的搜索结果列表里，具体位置通过属性position指定。

@UI.selectionField: 声明该字段渲染成搜索字段。

这些注解的详细定义在SAP help上能找到。这就是元数据驱动(metadata-drive development)的UI开发方式。这种方式实际将UI开发的大部分复杂度从应用开发人员身上转嫁到了Smart Template框架实现本身。使用这个框架，应用开发人员所需要做的就是专注于CDS view的开发，以及在view里定义UI注解。在运行时，由SAP UI5框架将这些元数据读取出来，然后负责生成原生的HTML代码。

这解释了为什么您在基于Smart Template的Fiori应用里找不到xml或者js view，因为UI布局压根就不再存储于这些前台资源里，而是维护在ABAP后台的CDS view里。

下图是之前提到的Service Order Fiori应用使用到的CDS view的层级结构。每个view的详细代码在我的博客里。

关于Smart Template的更多介绍，请参考我的公众号文章 Jerry的通过CDS view + Smart Template 开发Fiori应用的blog合集。

UI5 In SAP Cloud for Customer(C4C)

之所以要把C4C单独拿出来讲，是因为虽然C4C也基于SAP UI5，但是对SAP UI5的使用方式和SAP其他产品，如S/4HANA, SAP Revenue Cloud， SAP Engagement Center相比还有所不同。SAP成都研究院C4C开发团队的Yang Joey在他的微信公众号文章有详细的介绍：

SAP成都研究院C4C光明左使：SAP Cloud for Customer 使用SAP UI5的独特之处

Hybris Enterprise Commerce Platform(ECP)

按照使用场景可分为Storefront UI（前台电商页面）和Backoffice UI（后台管理页面）。

Storefront UI布局和使用方式均和我们每天用的淘宝京东等类似，采用JSP开发。

同前文介绍的CRM WebClient UI使用的BSP技术一样，在Hybris Storefront UI的JSP开发中，Hybris也封装了很多标准的UI元素供开发人员使用。在Hybris里把这些标准UI元素称为Tag（标签）。

比如下图使用标签ycommerce:testId来分页显示产品搜索结果：

这个标签的定义位于文件:

ext-template/yacceleratirstorefront/web/webroot/WEB-INF/common/tld/ycommercetags.tld

而标签的实现位于文件TestIdTag.java：

ext-template\yacceleratorstorefront\web\src\de\hybris\platform\yacceleratorstorefront\tags

同前面讲过的UI5控件的Renderer，WebClient UI元素的Renderer职责相同，该Java类也能看作是JSP标签的Renderer，负责在运行时渲染JSP tag testId 对应的原生HTML代码。

上图注释还提到，为了确保id唯一，pageContext内部维护一个计数器，每次生成页面元素后计数器加1。该计数器产生的整数值作为最后生成原生HTML div标签id属性的后缀，确保每个div标签有全局唯一的id。

而Hybris JSP标签这套确保div id属性全局唯一的实现方式，和WebClient UI竟完全一致。从下图一个WebClient UI页面的原生HTML代码中我们能轻易发现id属性值的整型后缀：

WebClient UI里id属性计数器的累加在下图第24行完成。

关于Hybris JSP标签的更多细节，请查看我的博客：

JSP attribute tag used in Hybris UI implementation and counterpart in ABAP BSP

以上仅仅是Hybris ECP storefront UI开发微观层面的描述。从宏观上来讲，这些JSP开发而成的界面如何组装起来最后形成用户看到的电商页面呢？类似SAP WebClient UI的Navigation Profile可以基于业务角色（Business Role）定义一系列UI以及其页面跳转关系，Hybris ECP也有类似的模块称为Web Content Management System（WCMS）：

在WCMS里可以定义一个页面的模板(Template), 模板里包含了不同的Page Slot，这些Slot里放置具体的UI Component。比如下图的homepage模板，定义了电商首页的布局，我们能观察到SiteLogoSlot位于TopHeaderSlot和ButtonHeaderSlot之间，包含了SiteLogoComponent，后者负责在电商页面上显示logo。

而UI component tag的渲染，分为渲染前，渲染中和渲染后三个阶段，分别对应renderItem方法中的三个子方法：

beforeItem

renderItem

afterItem

这三个方法分别对应了WebClient UI中的这三个子方法：

DO_AT_BEGINNING

RENDER

DO_AT_END

至于通过WCMS创建的template在运行时如何生成最终的HTML源代码，则是一个比较复杂的过程，这里限于篇幅不做详细介绍，大家可以参考Hybris官网上的帮助文档。

Salesforce UI

谈起Salesforce UI，会遇到以下一些名词：

Apex

Lightning Experience

Aura Framework

Lightning Component Framework

Visualforce

Jerry处于兴趣也在业余时间对这些概念做了粗浅的研究，详情可以参考我这篇微信公众号文章。

用JavaScript访问SAP云平台上的服务遇到跨域问题该怎么办

2018-06-06T06:11:14+02:00

解法1：Cross-Origin Resource Sharing

解法2：JSONP

解法3：自开发ProxyServlet

更多阅读

关于JavaScript的跨域问题(Cross Domain)的讨论, 网上有太多的资源了。国内的程序猿写了非常多的优秀文章，Jerry这里就不再重复了。

直入主题，最近我正在做一个原型开发：通过SAP云平台和SAP Cloud Connector把On-Premise系统上的ABAP function module STFC_CONNECTION 暴露出来，给微信消费。
这个function module的逻辑很简单，直接把输入参数REQUTEXT的内容不加任何处理，拷贝到输出参数ECHOTEXT。

具体操作步骤参考我的公众号文章：使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数
部署到SAP云平台后，通过如下的API endpoint进行调用：
https://demoi042416trial.hanatrial.ondemand.com/connectivity/api?userinput=

然后在我的微信消息服务器上发起如下的AJAX调用去消费（因为是POC，所以把API endpoint硬编码在第3行）：

遇到了意料之中的跨域错误: No 'Access-Control-Allow-Origin' header is present on the requested resource.

如何解决?

解法1：Cross-Origin Resource Sharing

如果服务器端的响应能够通过编程或配置去影响，那么可以借助Cross-Origin Resource Sharing，在HTTP响应结构中添加字段Access-Control-Allow-Origin，其内容根据实际业务赋以需要的origin字段即可。这里的origin在Jerry看来就是一个白名单。
解决方案参考我的博客：
Cross domain request in ABAP and Java

解法2：JSONP

用JSONP也能解决跨域问题，但这个方法同样需要在服务器端通过编程方式做一些处理。具体使用方式参考我的博客：
Play around with JSONP in nodeJS server and ABAP server

而我使用SAP云平台加上Cloud Connector将On Premise上的function module暴露到公网，这种方式开发人员无法对HTTP的响应头进行编程或配置。因此JSONP对于我原型开发解决跨域问题也没有帮助。
在SAP云平台的Mobile Service for Development and Operations cockpit里有对应的Cross Domain Access参数配置。不过我的原型开发没有用到SAP云平台Mobile Service这套架构，因此也不适用。

解法3：自开发ProxyServlet

接下来咋办？Jerry以前做CRM Fiori开发时，用的是Eclipse IDE，在本地起一个Tomcat，上面跑的Fiori应用也能通过localhost这个域访问到On-Premise系统域上的OData服务。当时咋不会遇到跨域问题呢？仔细回忆了一下，当时我们的Tomcat服务器上还部署了一个Proxy Servlet。Index.html发送的AJAX请求被ProxyServlet拦截，由ProxyServlet通过Java代码向On-Premise系统发起请求。请求得到响应之后，ProxyServlet再将其发送给Index.html。
这种类型的Servlet其原理在我的这篇博客里有详细介绍：
Explore the com.sap.ui5.resource.ResourceServlet

思路清楚后，写代码实现就很容易了。上图对应的Java Web项目的源代码在我的github上：

1. index.html里发送的AJAX请求实际指向的处理者是ProxyServlet：注意下图第三行的请求url路径中的proxy。

2. 开发一个ProxyServlet，拦截url路径里包含proxy的那些请求。回到我的原型开发需求，SAP云平台上的API消费如今通过ProxyServlet来实现，为简单起见，我将API endpoint硬编码在ProxyServlet里。

经过测试，能按照期望的方式工作：域localhost的AJAX请求能够成功访问SAP云平台上的API：

写完之后我在Google上搜了一下，发现SAP已经在github上发布了一个标准的Proxy project，用于处理这种JavaScript跨域访问的问题，大家有兴趣可以了解一下：

Calling BAPIs in the SAP S/4HANA Public Cloud

2019-06-14T13:58:57+02:00

Introduction

About this series

In this blog series I will describe the use of RFC and BAPI technologies in the context of integration of the SAP S/4 HANA Public Cloud with On-Premise Systems. This kind of landscape is also called a Hybrid Landscape and we may as well talk about Hybrid Integration Scenarios.

You will learn which technical components you need and how to configure them. The blog series is split into multiple parts. The first blog post is about the underlying concepts and the positioning and you are reading it right now. The details of the test case are described in individual blog posts.

Some background

The specific case I am covering is the usage of "traditional" SAP integration technologies (RFC and BAPIs) which were partly whitelisted for usage with SAP S/4HANA Public Cloud. These technologies have been around for more than 20 years and were the work-horse concepts in the SAP ERP On-Premise world. But for the SAP Cloud they will only be required during a transition phase and will be replaced by SOAP and ODATA APIs as explained a bit further down.

To give you some insight how to use them during this transition phase, I examined various test cases to illustrate what can be done. Please consider them as starting point for your own examinations. Of course I would be happy to learn about what you have tried and achieved. Just leave a note in the comment section below.

BAPIs and RFC are sort of "ancient" SAP concepts for integration resp. communicating business information between systems. BAPI is an abbreviation for "Business Application Programming Interface". The offer a stable interface with standard methods to access SAP Business Objects (e.g. Sales Orders) which can be called externally. If you want to learn more I suggest you take a look at this article in the SAP Documentation.

RFC is a technical protocol (Remote Function Call) which can be used to call RFC-enabled ABAP function modules from the outside. It was "the" protocol and came in various flavours, most importantly as so-called tRFC-Call (transactional RFC) which were of paramount importance for data exchange via ALE (Application Link Enabling), usually in the IDoc-Format. BAPIs are technically function modules of this type. We used to develop them ourselves based on the BAPI Programming Guide and they could also be called asynchronously.

Much more important than programming a BAPI yourself were those standard BAPIs which were delivered as part of the SAP standard. If you search for function modules starting with "BAPI_" in an SAP ERP System, you will find several thousands of them. This shows the importance of this concept in former times.

BAPIs in SAP S/4HANA Cloud – When And How To Use Them

The standard way of integrating your SAP S/4HANA Cloud solution is with the help of SAP Best Practices and whitelisted APIs. For more information about these topics take a look at our “Integration with SAP S/4HANA Cloud” openSAP course and at our “SAP S/4HANA Cloud Integration Checklist” blog post.

The limited positioning of BAPIs in the context of SAP S/4HANA Cloud had long been explained in SAP Note 2447593 and remains unchanged.
Here a quick recap:

SAP only supports BAPIs for the purpose of integrating SAP S/4HANA Cloud with SAP on-premise solutions (see also SAP Note 2447593)

BAPIs listed in that note shall only be used until a successor API (OData or SOAP) has been made available

If you need to use a BAPI interface for integrating with a 3^rd party solution please follow the exception process as described in SAP Note 2653671

My Test Cases

In the other parts of this Blog I will examine the following test cases:

Calling a BAPI in the SAP S/4HANA Cloud from an on-prem SAP ERP System
This was my starting point of this learning journey. I found out which components I needed and how to configure them. It was mainly about the SAP Cloud Connector (SCC) and how to set it up. I had never done that before and it was very educational. Once I got it to work the rest was straight forward. I will include a detailed description of the set-up process of the SCC which worked for me.

Calling a BAPI in the SAP S/4HANA Cloud from SAP Process Orchestration
Building on top of test case 1, my colleague hoang.vu3#overview set up a scenario to call the BAPI from SAP Process Orchestration. This is a scenario that makes a lot of sense in a Hybrid Landscape because PO is a widespread tool in SAP-heavy On-Premise Landcapes.

Calling a BAPI in the SAP S/4HANA Cloud from a non-SAP system
I simulated this with a JAVA Program I ran in Eclipse. There are various RFC libraries available, the most prominent being the JCO Libraries also called SAP Java Connector.

Calling a BAPI in an SAP On-premise system from the Cloud
In this case I used SAP Cloud Platform Integration to make the call. It is sort of the reverse of test case 2 and has also some significance in real application scenarios.

Calling a BAPI in the SAP S/4HANA Cloud from the Cloud
Direct RFC calls between SAP Cloud Components are not supported. What I wanted to find out was if it works if I take a detour via OnPrem.

Important Reminder

Please keep in mind what is pointed out in the section "BAPIs in SAP S/4HANA Cloud – When And How To Use Them"! What I describe in this series should be considered as experimental work and not as a recommendation for productive scenarios. If you want to use BAPIs for productive Cloud scenarios you must follow the process described in the notes mentioned above (SAP Note 2653671 and SAP Note 2447593).

Preparation

What I used

An SAP Cloud Platform Account. It is needed to connect the SAP S/4 HANA Cloud Tenant and the SAP Cloud Connector.

An SAP S/4HANA Public Cloud Tenant + user with administrative privileges

An SAP Cloud Connector + user with administrative privileges

An SAP ERP Backend System + user with RFC privileges

SAP Process Orchestration + development user

SAP Cloud Platform Integration Service + development user

Eclipse (or comparable) + SAP Java Connector Libraries

PostMan or SOAPUI

The ERP Backend is especially useful to access the documentation of individual BAPIs. Call transaction BAPI to see the it. Use transaction SE37 to access the ABAP Implementation of the BAPI.

Please be aware: Without access to an ERP backend you will have a hard time to obtain the BAPI documentation. It is not available online anymore or at least I couldn't find any. You can get a WSDL for a BAPI from an OnPrem ERP Backend or S/4HANA Backend via SAP Process Orchestration, too.

Helpful Knowledge

How to do the Communication Setup in SAP S/4HANA Cloud: Communication Systems, Users and Scenarios

Finding your way in the ABAP Workbench

Basic RFC knowledge

Basic BAPI knowledge

Some JAVA

How to develop simple IFlows in SAP Cloud Platform Integration.

Quick Guide to set up the Cloud Connector

In case you don't have an SAP Cloud Connector already available you need to set it up from scratch. There are a numerous blogs available how to do this. This Blog by Ali Chalhoub explains it very nicely and in much detail. Actually you should be fine to go with the documentation in the SAP Help Library. This part refers to online information resources which describe all the necessary steps in sufficient detail. The description is based on the 1905 documentation material. Steps 1-4 can be skipped if an already operational SCC-Setup can be used. Here is a quick overview if the steps:

Step List

Get the picture
Carefully read the chapter “Integrating OnPrem Systems” (1905 Version) in section “General Functions for the Key User” of the SAP Online Help.

Prepare and Configure the Cloud System
Configure Communication Scenario SAP_COM_0200 as described in “Integrating OnPrem Systems (Steps 1-7)”.

Install the Cloud Connector
Download and Install the Cloud Connector “Integrating OnPrem Systems (Step 8)”
(SAP Cloud Platform Connectivity: Installation)

Configure the Cloud Connector
Do the initial configuration of the Cloud Connector “Integrating OnPrem Systems (Step 9)”
(SAP Cloud Platform Connectivity: Initial Configuration)

Set up the Service Channel
Configure the Service Channel to your SAP S/4 HANA Cloud Tenant
(Setting Up the Connection from On-Premise Systems to SAP S/4HANA Cloud)
(Configure a Service Channel for RFC)

Test the Connection

Use the Setup

Preparing the SAP S/4 HANA Cloud System

Once the SCC Setup is working properly a Communication Scenario with BAPIs can be used:

Take a look at OSS-Note 2447593 - Available BAPIs in S/4HANA Cloud for integration to SAP on Premise solutions to identify the Communication Scenario you want to use.

Activate the Communication Scenario in the S/4HANA Cloud System. My example: Read an Equipment.

For example: BAPI_EQUI_GETDETAIL. The note shows we need to activate SAP_COM_0319.

Go to Communication Arrangements and create a new arrangement from Scenario SAP_COM_0319.

Pick the same communication system as for SAP_COM_0200. The inbound user is filled in automatically since it is attached to the communication scenario.

In the arrangement you can see the available BAPIs. Save the arrangement:

Your components should now be ready for operation!

In the next blog post I will go into detail for test case 1.

Calling a BAPI in the SAP S/4HANA Cloud from a non-SAP system

2019-07-03T18:42:57+02:00

Introduction

In the previous blog post of this series we saw how to call a whitelisted BAPI in the SAP S/4HANA Cloud using SAP Process Orchestration. Now we are going to take a look how we can do the same from a non-SAP application.

Calling a BAPI in the Cloud from non-SAP systems ( e.g. a JAVA program)

Non-SAP systems can make RFC-Calls to the S/4HANA Cloud as long as they adhere to the RFC standards. That is usually done by implementing the libraries which were published by SAP. There are numerous solutions available which implement the RFC protocol this way and are certified. These 3rd party products usually come along with a guide which explains how to integrate with SAP systems. For SAP On-Premise solutions it has been like this for many years. For the SAP S/4HANA Cloud it works as well (as we will see) but there are some official restrictions:

Please keep SAP Note 2447593 in mind which is saying that RFC should only be used to integrate S/4 HANA Cloud with SAP OnPremise-Solutions (and be it, that it is SAP PO). So whatever you do with non-SAP systems, RFC/BAPI and the SAP S/4HANA Cloud is at your own risk.

Preparation

What I used

A functional SAP Cloud Connector Instance + user with administrative privileges

An SAP S/4 HANA Public Cloud Tenant + user with administrative privileges

Eclipse

SAP JCO libraries

What I did

Download the JCO libraries

Import the JCO libraries into Eclipse

Set up the JCO Destination File

Test the connection and the BAPI call with the sample programs

Setting up Eclipse

One way of simulating a non-SAP System is making use of a SAP Connector, the JCO libraries. You can find them here: SAP Java Connector. In my example I set up an Eclipse Project and implemented a program that was based on the samples provided with the JCO library. I had to play around a little bit but in the end it worked.

Being not much of a Java guy, I was inspired by 2 Blogs from varun.boyina#overview which helped me to set up the example.

SAP UI 5 – CALLING RFC THROUGH SAP JCO

SAP UI5 – Calling Servlet(which Returns Single Value) using JQUERY AJAX

Initially I wanted to go via the good old RFC libraries which were used to be delivered with the SAP GUI and included such useful programs like startrfc.exe but that isn’t the case anymore. You can still download a NW RFC library if you want to (see here) but startrfc doesn’t work the way I thought it did anymore or maybe I’m mixing things up and don't remember it properly. The last time I actually used startrfc was about 15 years ago. Programs change, memories fade…

Eclipse and the JCO worked fine for me and anybody who is more familiar with Eclipse and Java should get along easily.The project structure in Eclipse looks like this:

JCO Destination File

You can either put the destination details into the program or put an RFC destination file into the project. This file contains the information to establish a connection:

#for tests only !

#Tue May 15 16:51:44 CET 2019

jco.client.lang=EN

jco.client.client=100

jco.client.passwd= <Put the password of the S4HC API User of the CommScenario here>

jco.client.user=<Put the name of the S4HC API User of the CommScenario here>

jco.client.sysnr=00

jco.client.ashost=<Adress of the SCC, e.g. xxx.mo.sap.corp>

If you get a RFC_NO_AUTHORIZATION in BAPI_METADATA_GET error you could try this:

jco.destination.repository_roundtrip_optimization=0

(Thank you Jacky Liu, Ban Luo and Echo Chen for finding the solution and testing it)

In the example the file is called "SCC_PRACTICE.jcoDestination". You can see it in the project structure above. You need to put your own destination details for passwd, user and ashost.

Sample Program

With the program below I was able to read equipment data from the S/4 HANA Cloud. It is a very basic program and not dynamic at all. But it shows that actually not much is required to do the calls. If you want to get into the details I recommend that you read the documentation: SAP Java Connector (Standalone Version).

package jne;







import com.sap.conn.jco.AbapException;

//	import com.sap.conn.jco.JCoContext;

	import com.sap.conn.jco.JCoDestination;

	import com.sap.conn.jco.JCoDestinationManager;

	import com.sap.conn.jco.JCoException;

//	import com.sap.conn.jco.JCoField;

	import com.sap.conn.jco.JCoFunction;

//	import com.sap.conn.jco.JCoFunctionTemplate;

	import com.sap.conn.jco.JCoStructure;

//	import com.sap.conn.jco.JCoTable;

//  import com.sap.conn.jco.ext.DestinationDataProvider;



	/**

	 * basic examples for Java to ABAP communication  

	 */

	public class RFCBAPI

	{

//		static String SCC = "SCC_JNE";

		static String SCC = "SCC_PRACTICE";

		

	      	  	    

	    /**

	     * This example demonstrates the destination concept introduced with JCO 3.

	     * The application does not deal with single connections anymore. Instead

	     * it works with logical destinations like ABAP_AS and ABAP_MS which separates

	     * the application logic from technical configuration.     

	     * @throws JCoException

	     */

	    public static void step1Connect() throws JCoException

	    {

	        JCoDestination destination = JCoDestinationManager.getDestination(SCC);

	        System.out.println("Attributes:");

	        System.out.println(destination.getAttributes());

	        System.out.println();





	    }

	    

	   

	    public static void step5CallBAPI() throws JCoException

	    {

	       	System.out.println("Initiating");

			JCoDestination destination = JCoDestinationManager.getDestination(SCC);

			System.out.println("Calling:");

			JCoFunction function = destination.getRepository().getFunction("BAPI_EQUI_GETDETAIL");

			if(function == null)

				throw new RuntimeException("BAPI_EQUI_GETDETAIL not found in SAP.");

				try

					{

						function.getImportParameterList().setValue("EQUIPMENT", "000000000010000000");

						function.execute(destination);

					}

				catch(AbapException e)

					{

					System.out.println("ABAP Exception");	

					System.out.println(e.toString());

					}

				try

					{

					System.out.println("BAPI_EQUI_GETDETAIL finished:");

//					System.out.println(function.toXML());

 					printStruct(function,"DATA_GENERAL_EXP");

//					printStruct(function,"DATA_SPECIFIC_EXP");

//					printStruct(function,"DATA_FLEET_EXP");

//					printStruct(function,"RETURN");

				  					}

				catch(Exception e)

					{

						e.printStackTrace();

					}

	    }



	    

	    public static void step6PrintBAPI() throws JCoException

	    {

	       	System.out.println("Initiating:");

			JCoDestination destination = JCoDestinationManager.getDestination(SCC);

			System.out.println("Calling:");

			JCoFunction function = destination.getRepository().getFunction("BAPI_EQUI_GETDETAIL");

			if(function == null)

				throw new RuntimeException("BAPI_EQUI_GETDETAIL not found in SAP.");

				try

					{

						function.getImportParameterList().setValue("EQUIPMENT", "000000000010000000");

//						function.getImportParameterList().setValue("REQUEST_INSTALLATION_DATA", "X");

						function.execute(destination);

					}

				catch(AbapException e)

					{

					System.out.println("ABAP Exception");	

					System.out.println(e.toString());

					}

				try

					{

					System.out.println("BAPI_EQUI_GETDETAIL finished:");

					System.out.println(function.toXML());

//					System.out.println(function.getFunctionTemplate());

// 					printStruct(function,"DATA_GENERAL_EXP");

//					printStruct(function,"DATA_SPECIFIC_EXP");

//					printStruct(function,"DATA_FLEET_EXP");

//					printStruct(function,"RETURN");

				  					}

				catch(Exception e)

					{

						e.printStackTrace();

					}

	    }

	    

	    public static void printStruct(JCoFunction BAPI, String StrucName) {

	    	

	    	System.out.println("\n" + "Structure: " + StrucName);

	    	JCoStructure BAPIStruc = BAPI.getExportParameterList().getStructure(StrucName);

	    	for (int i = 0; i < BAPIStruc.getFieldCount(); i++)

	        {

            	System.out.println(i + ": " + BAPIStruc.getString(i));;

	        }	

	    }

	    

	    

	    public static void main(String[] args) throws JCoException

	    {

//			Set Destination	 



//	    	step0DestinationFile();

	        step1Connect();

//          step2ConnectUsingPool();

//	        step3SimpleCall();

//	        step4WorkWithTable();

//	        step4SimpleStatefulCalls();

//            step5CallBAPI();

            step6PrintBAPI();

	    }

	}

Conclusion

What I learned from this test case

With this test case I brushed up my Java a little bit. For somebody who has used the JCO libraries already in the OnPrem world there is nothing new. The implementation is the same, just the RFC Destination is pointing to the SAP Cloud Connector.

Your Feedback

Please let me know if the description was helpful and you were able to set up the same test case. Any feedback how to improve this blog post is welcomed! Please put it in the comment section.

What’s next

Next time I will show you how to call a BAPI on-premise from SAP Cloud Platform Integration. It's also the preparation for the final test case in which I do a call from the Cloud and back. Check back soon!

SAP Hana XSA Code Jam en Ciudad de Mexico ?? 2019

2019-08-03T03:31:09+02:00

Este 21 de Agosto en la Ciudad de México de 9 AM a 3 PM estaremos llevando a cabo un SAP #HANA #XSA Code Jam junto con el SAP Inside Track Mexico 2019 un evento donde podrás desarrollar una solución utilizando diversas tecnologías, plataformas y herramientas de SAP. Se le presentará un escenario de inicio a fin, en el que podrá ver cómo las diferentes tecnologías se integran y trabajan juntas mientras construye su solución.

Es un evento GRATUITO, pero como es un evento práctico tiene ciertos requerimientos para poder participar

Debes traer tu propia computadora portátil) y de preferencia q tengas #HANA #Express instalado

La ponencia estará dictada por la catedrática lsubatin de @SAP, experta en la materia, que estará en el sitio para responder a sus preguntas y compartir información y consejos relevantes.

If you are a SAP programmer, who seeks to know or update,

Made your pre-register ASAP

Organizers:

maria.antonieta.lopez

jhonjairoteran#overview

9958e4b6df99431a84a41b015b639ac8#overview

Important Facts

Date and Hours: August 21, 2019 from 09:00 to 15:00 hrs.

Address: Prolongación Paseo de la Reforma 600, Santa Fe, Zedec Sta Fé, 01210 Ciudad de México, CDMX

Hashtag:

#CodeJamMEX

CONTACT

?✉️ SAP InsideTrackMexico@gmail.com

@InsideTrackMEX

@SAP .Inside.Track.Mex

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector - Part 1/3

2020-04-14T14:11:48+02:00

Introduction

Is it possible to produce/send a message from SAP to KAFKA using ABAP? What about is it possible to consume/receive a message in SAP from KAFKA?

In this blog I'll demonstrate how it is possible to do this using the SAP Java Connector and the Apache Java API.

Use case

We live in a world where we need to reduce data friction between systems. Let's suppose you are asked to send the details (say a business partner) out to a Kafka topic as changes happen inside SAP. As a developer you've located the perfect user exit/BADI that gets triggered on/after save where you can put your ABAP code. Now you are stuck. How do you go from taking all the data in ABAP memory, and pass it to KAFKA?

Kafka cannot receive HTTP calls out of the box. You need to use a Java API, or a third party API, or setup an intermediate server to translate HTTP calls to call Kafka.

What are my options?

There are heaps of options to produce/consume messages in KAFKA. Some free, others are not, all with their pros and cons. Apache has a Java client, and Confluent.io has a tonnes of options - .NET, Go, Python etc. There are also heaps of third party options to support other languages as well.

ABAP to Kafka connector? Well, you are out of luck here (at least at the time of this article).

The obvious choice for the unsupported languages is to host a HTTP/REST API for any systems to call. Confluent has a REST support as well.

There are also options where you can stream straight from the database/HANA/hadoop as well. I'm not quite sure how that's going to work for SAP data, where the data is spread across multiple tables and don't always make sense to the outside world.

You can spend days exploring the different options, so choose the one that suits.

What about standard SAP and third party enterprise products?

SAP of course have their standard solutions, such as SAP Data Hub, SAP HANA Connector, and possibly others. I have not tried them. There are also other third party companies that provide enterprise solutions at a cost, such as Ad. Google it or search on SDN, all with their pros and cons.

When I first started, I was hoping there could be a standard SAP KAFKA class that I can call to send a message, but there isn't one. I've read a blog that talked about using ABAP Channels but it didn't work for us.

Disclaimer

I'm not here to say which solution is better as I don't know. My intention is not to compete with the various products/solutions out there either. As a techie, I just want to see what is possible. To me this option might be the cheapest one without the need of extra hardware or too much setup.

This is not a tutorial on Java, or KAFKA, AWS, or how to run your own Netweaver environment. It does require knowledge on all of these to follow what I'm doing, so let's hope you can follow along.

This is also not a production scale demo. There are many tweaks you can do to make this scale.

This demo will cost you money for cloud hosting if you were to follow.

Hopefully some of you will find this interesting. It took me a couple of nights to understand how to setup a JCO server properly as the standard SAP documentation is not the best.

What am I going to do?

Setup a demo Netweaver system using SAP CAL (Cloud Appliance Library) in AWS

Setup some tools that I'm going to use in the EC2 instance

Setup KAFKA

Setup SAP Java Connector (JCo)

Create/configure SAP Java Connector Server

Produce a message to a KAFKA topic from ABAP

Consume a message from a KAFKA topic and call ABAP

Versions

KAFKA - 2.12

SAP Java Connector (JCo) - 3.0

SAP NetWeaver AS ABAP 7.51 SP02 on ASE

Source code

I've put my code on github.... you might find it useful.

https://github.com/joymike/sap_kafka_demo.git

Blog links

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector – Part 1/3

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector – Part 2/3

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector – Part 3/3

Architecture

Setup a demo NW system in SAP CAL

If you do this, it will cost you money!!!

SAP Cloud Appliance Library (CAL)

Go to SAP Cloud Appliance Library - https://cal.sap.com/, register and create a new "SAP Netweaver AS ABAP 7.51 SP02 on ASE" instance on AWS. You will be presented with many solution choices, so you can pretty much choose any NW instances available. Some options are slightly cheaper than others. You can choose other cloud providers like Google Cloud or Azure. Like I said I'm not here teach you how to use CAL here, so I'm sure you can google it and find out.

When I first tried to do so, it didn't work, but a day later I got an email and I went in again and it worked again. I can choose from 113 solutions, it's really quite fascinating!

Cost

Tips

Download the Key and save it somewhere (Don't lose it)

Remember the password you entered to create the instance with CAL. There's no way of recovering (that I know of), and you'll need to that to use the SAP system.

Amazon AWS EC2

As you can see there are two instances created. These are not covered in Amazon AWS free tier so they will cost you some money.

After a while, I have 2x AWS EC2 instances:

a SUSE Enterprise Linux server instance installed with the SAP Netweaver with HANA backend, installed and ready to go.

a Windows instance with SAPGUI and all the development tools you'll need (you may or may not need this, you can delete it to save some money if you got all the tools installed on your laptop already)

Tips

I have SAPGUI installed on my laptop

I've attached an elastic IP to my instances so that the Public DNS and IP does not change after EC2 restart.

Turn of your EC2 instances if you are not using it. It cost less than USD$0.50 per hour but it does add up over time.

Setup cost alarms in AWS to warn you if you go over your budget.

I've setup a AWS CloudWatch event that calls a Lambda function to switch off my EC2 instances every hour to safe cost. Yes it's inconvenient but I make sure I don't get a nasty surprise.

Again, this is not a tutorial about AWS, so go google it and I'm sure you can find out 😄

SSH into the Linux instance

You can use PUTTY (for Windows) or just terminal for Mac. I'm sure you can work out how to do this with a quick googling around.

Now notice the user created is "root", and password is the same password you entered for CAL when you created the instance. You need to provide the key/cert to log in.

For Putty you will need to convert the cert using PUTTYGEN first.

See you in part 2!

Leave me some comments so I know how I went.

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector – Part 2/3

2020-04-14T14:12:29+02:00

This is the second part to demonstrating how to get SAP Netweaver to produce/consume messages in KAFKA from SAP.

Link to part 1 Part 1

If you are just keen to see the results, go to Part 3.

Below will cover the following:

Connect to your SAP server using SAPGUI
- Install license
- Developer Key

Setting up tools
- Java Development Kit
- Nano

Setting up KAFKA

Setting up SAP Java Connector (JCo)

Just to reiterate, I didn't use the windows EC2 instance that had all the developer tools. I only used the SUSE linux instance installed with the SAP Netweaver backend.

Source code

I've put my code on github.... you might find it useful.

Setup your SAP system

You can either use your windows EC2 instance's SAPGUI and it is already setup with a system to connect to.

If you have your own SAPGUI installed on your own machine. The application server should point to your elastic IP of your EC2 instance, or else it may change after every EC2 restart.

First log in

Client 001

User: DEVELOPER

Password: What you entered when you created your CAL instance

Install trial license

See here , or google how to get a minisap license.

In a nutshell, get your hardware key from transaction transaction SLICENSE.

Go to https://go.support.sap.com/minisap/#/minisap and generate a license for A4H, enter your hardware key.

Upload it to SLICENSE and you are done.

Developer key

The user DEVELOPER should already have a developer key assigned, so in case you are wondering, you don't need one. Just don't go and create your own user and expect to be able to get a developer key for it (I found out the hard way).

Setting up tools

First you need to make sure you can SSH into your EC2 instance.

JDK

Both KAFKA and SAP Java Connector requires Java, so it makes sense to start installing that first.

From memory a Java 1.6 comes with the EC2 instance but it is too old for KAFKA, so we need a newer one.

To install

Run command:

sudo zypper --non-interactive install java-1_8_0-openjdk-devel

To test:

Run Command:

java -version

Run Command:

javac

If they didn't return any error, you are good to go.

Nano

This step is entirely optional. I need an editor in linux, and I like to use nano. You can use whatever you like such as vi.

To install

Run Command:

wget https://download.opensuse.org/repositories/openSUSE:/Leap:/15.1/standard/x86_64/nano-2.9.6-lp151.2.3.x86_64.rpm



sudo rpm -i nano-2.9.6-lp151.2.3.x86_64.rpm

If this link does not work (because I have no control over it, search for somewhere that that might have a nano rpm distribution)

To test:

nano <any file>

To exit:

Ctrl + X

Setting up KAFKA

Install

Run Command:

curl -O http://apache.mirror.amaze.com.au/kafka/2.4.1/kafka_2.12-2.4.1.tgz



tar -xvf kafka_2.12-2.4.1.tgz



rm -rf kafka_2.12-2.4.1.tgz



sudo ln -s ~/kafka_2.12-2.4.1 /opt/kafka

Let's explain

The script will first go to Apache and download KAFKA. If the link in the above command does not work, then change it to the latest from Apache.

The EC2 instance will download KAFKA tgz file, untar it and we create a symbolic link /opt/kafka to the decompressed kafka directory.

That's it... now KAKFA is installed!

Configure

We are going with the most basic configuration/setup here, with single zookeeper, single KAFKA server. It's up to you to explore more complex setup.

Now I'm going to refer to the Apache quick start guide since I can't explain it any better and there's no point of me repeating either.

In short, we are going setup one zoo keeper (on port 2181), one KAFKA server (on port 9092). Remember these ports as you will see code referring to them later.

I run the following script to start the zookeeper and KAFKA server. You need to repeat this after each restart.

#!/bin/bash

export KAFKA_HOME="/opt/kafka"

export KAFKA_HEAP_OPTS="-Xmx512M -Xms256M"

nohup sudo $KAFKA_HOME/bin/zookeeper-server-start.sh $KAFKA_HOME/config/zookeeper.properties > /dev/null 2>&1 &

sleep 2

nohup  $KAFKA_HOME/bin/kafka-server-start.sh  $KAFKA_HOME/config/server.properties > /dev/null 2>&1 &

sleep 2

Note that I set the KAFKA heap to be smaller as the EC2 instance struggled with the default memory settings.

Remember to chmod it to execute.

chmod +x kafka_start.sh

See code here

Create a topic:

I'm going to create a topic "my-kafka-topic". You can call it whatever you want. You only need to do this once. If you get an error it means your zookeeper or KAFKA server is not started properly.

/opt/kafka/bin/kafka-topics.sh --create --topic my-kafka-topic --zookeeper localhost:2181 --partitions 1 --replication-factor 1

Test it

Produce a message

/opt/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-kafka-topic

Consume the message

In another SSH session, run this:

/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-kafka-topic --from-beginning

Setting up SAP JCo

Make sure you get JCo 3.0 and not 3.1

I paid a hefty price of trying to get version 3.1 to work, only to wasted hours on trying to fix a ARPCRFC fast serialization error. So I'm going to use version 3.0 here

Where to download

https://support.sap.com/en/product/connectors/jco.html

Install

Transfer and unzip the file to the EC2 instance

I suggest you download the "sapjco30P_20-10005328.zip" file first in your desktop and upload it to the EC2 instance. I suggest you either put it somewhere public on the internet and use "wget" or "curl" in the SSH terminal to download. I put it in an S3 bucket and use AWS CLI commands to retrieve it - do whatever works for you.

After the file is on the server, you should unzip it to the folder sapjco30.

mkdir sapjco30

cd sapjco30

aws s3 cp s3://<my-s3-bucket>/sapjco30P_20-10005328.zip sapjco30P_20-10005328.zip

unzip sapjco30P_20-10005328.zip

tar -xvf sapjco30P_20-10005328.tgz

If you are not using S3 bucket for transfer, skip the s3 line.

That's it. SAP Java Connector is ready to be used!

Your directory should look like this.

Now let's get the simple JCo Server to work. JCo server is basically the receiver of an RFC calls from any NW system. You need to first register this "JCo Server" with the SAP system, kind of like a handshake, so that the NW system knows where to call.

Create RFC Destination

Name	ZMP_JCO_SERVER
Type	T
Program ID	ZMP_JCO_SERVER
Activation type	Registered Server Program

Test the RFC Destination

It should return an error for now... don't worry... it will work later on.

The error means it can't connect to the JCo server.

Configure the JCo Server

I'm going to use the stock standard JCo Server example provided by SAP. You can make this a lot more complex and scalable and performant.

Create the JCo Destination file

This bit took me hours to figure out, as I couldn't find any documentation that explains this. Perhaps it is straight forward. Standard HTML documentation that comes with the zip file shows you the code and assume you to know how to run it.

This tells the JCo Server code where our SAP system is. The JCo Server will use this to call SAP system to register a program ID.

EXT_SERVER.jcoServer

#A sample confidguration for a standard registered server 

#Replace the dummy values and put this file in the working directory.

#In eclipse environment it is the project root directory.

jco.server.connection_count=2

jco.server.gwhost=localhost

jco.server.progid=ZMP_JCO_SERVER

jco.server.gwserv=sapgw00

jco.server.repository_destination=ABAP_AS1

Make sure you enter the same program Id as the RFC destination file.

For the registration, the ABAP_AS1 is required as the JCo server makes a call to SAP.

ABAP_AS1.jcoDestination

#Sample destination configuration when using an application server over CPIC

#Replace the dummy values and put this file in the working directory.

#In eclipse environment it is the project root directory.

jco.client.ashost=vhcalnplci

jco.client.sysnr=00

jco.client.client=<sap client>

jco.client.user=<sap user>

jco.client.passwd=<sap password>

jco.client.lang=en

Change your ashost to the server name. localhost might work, haven't tried.

Compile the jco server example:

Edit the StepByStepServer.java file that comes with the Jco zip file.

Configure the server name to be the name of your file.

DESTINATION_NAME=Program ID of RFC Destination.

    static String SERVER_NAME1 = "EXT_SERVER";

    static String DESTINATION_NAME1 = "ZMP_JCO_SERVER";

Comment out these lines.

    public static void main(String[] a)

    {

        step1SimpleServer();

//      step2SimpleServer();

//      step3SimpleTRfcServer();

//      step4StaticRepository();

    }

Run

javac -cp ~/sapjco30/sapjco3.jar:/opt/kafka/libs/* StepByStepServer.java



java -cp ~/sapjco30/sapjco3.jar:/opt/kafka/libs/*:. StepByStepServer

Test it

Test the RFC destination

It's working!

Test the function module

Go to transaction SE37 and call function STFC_CONNECTION with the RFC destination.

The call is successful. The Java code response with "Hello World".

The call is successfully received by the JCo Server.

Finally, all the bits and bobs are set up... Now... back to why we are trying to do this, we want to be able for ABAP to call a java program using Java Connector, and produce a message on KAFKA... See Part 3.

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector – Part 3/3

2020-04-15T00:36:31+02:00

This is the final part of my blog.... we are now going to join the dots together.

The funny thing with doing a proof of concept on AWS is like getting a taxi ride... every minute counts... 🙂

Let's recap.

We now have an EC2 instance running in AWS with:

SAP NW backend

RFC destination setup

KAFKA setup and we can produce and consume messges from a topic "my-kafka-topic"

SAP JCo Server setup and connection established with the SAP NW

Now, back to the fun part.

Produce a message from SAP to KAFKA

I copied the Java code from "Tutorialspoint.com" and put it inside StepByStepServer.java provided by SAP. See SimpleProducer.java from https://www.tutorialspoint.com/apache_kafka/apache_kafka_simple_producer_example.htm

(I will not take credit for this code.)

Compile and run the code

See code here

You need the following files:

ABAP_AS1.jcoDestination

EXT_SERVER.jcoServer

StepByStepServer.java

Now this StepByStepServer.java file is a combination of the SAP example "StepByStepServer.java" and some code I copied from here. I didn't spend too much time on making the code pretty and neat. I just did the necessary to make it work so please don't judge.

What did I change in StepByStepServer.java:

    static String SERVER_NAME1 = "EXT_SERVER";

    static String DESTINATION_NAME1 = "ZMP_JCO_SERVER";

In the handleRequest method, I added the following:

            String message = function.getImportParameterList().getString("REQUTEXT");



            // Assign topicName to string variable

            String topicName = "my-kafka-topic";



            // create instance for properties to access producer configs

            Properties props = new Properties();

            // Assign localhost id

            props.put("bootstrap.servers", "localhost:9092");

            // Set acknowledgements for producer requests.

            props.put("acks", "all");

            // If the request fails, the producer can automatically retry,

            props.put("retries", 0);

            // Specify buffer size in config

            props.put("batch.size", 16384);

            // Reduce the no of requests less than 0

            props.put("linger.ms", 1);

            // The buffer.memory controls the total amount of memory available to the

            // producer for buffering.

            props.put("buffer.memory", 33554432);

            props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");

            props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

            producer = new KafkaProducer<String, String>(props);

            producer.send(new ProducerRecord<String, String>(topicName, message, message));

            function.getExportParameterList().setValue("RESPTEXT", "Message sent successfully");

            System.out.println("Message sent successfully");

            // producer.close();

What the code does is take the text passed from the STFC_CONNECTION function module, and call the Apache KAFKA producer API with it. It's that simple.

Compile and run. Notice I need to put both JCo and KAFKA libraries in the classpath now.

export KAFKA_HEAP_OPTS="-Xmx512M -Xms256M"

javac -cp ~/sapjco30/sapjco3.jar:/opt/kafka/libs/* StepByStepServer.java

Run the JCo Server

java -cp ~/sapjco30/sapjco3.jar:/opt/kafka/libs/*:. StepByStepServer

Start KAFKA consumer

/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-kafka-topic

Call RFC function module

Result

Here's a link to the youtube video for the result

https://youtu.be/giAMdDeKUs0

Consume a message using the Java connector client and call RFC

Now let's try the other way. Someone changed a transaction outside and published to a KAFKA topic and SAP wants to know about it and do something with it.

The flow is:

Message is produced to KAFKA topic

Java client (with Java Connector) consumes the message.

Java client calls SAP RFC

SAP RFC do something with the message.

Setup and run the JCo Client

See code here

You need the following files:

ABAP_AS1.jcoDestination

SapKafkaConsumer.java

SapKafkaConsumerDemo.java

Now let's explain.

is a copy of the SimpleConsumer.java which I borrowed from here as mentioned, combined with the code from the StepByStepClient.java from the SAP example.

The code can already consume a message from a KAFKA topic "my-kafka-topic", and I take that message and call function STFC_CONNECTION in SAP with the message.

The function will echo back the text showing it has successfully received it.

In the doWork method which is called when a message is received, I've added the code to call function STFC_CONNECTION. It should be straight forward what the code does.

Compile and run the Java client

javac -cp ~/sapjco30/sapjco3.jar:/opt/kafka/libs/* -Xlint:deprecation *.java

java -cp ~/sapjco30/sapjco3.jar:/opt/kafka/libs/*:. SapKafkaConsumeDemo

Produce a message to KAFKA topic

/opt/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-kafka-topic

Results

Voila.

Here's a youtube video.

In summary, it is possible and also not too difficult to do so.

What we now need to explore is how to productionize this solution, how to make this HA/DR etc. I'm still have some unanswered questions on how this can handle massive volume in an enterprise environment, or whether the JCo server and client should be on a separate instance.

Anyway, thanks for you time, I hope you find this interesting. Leave me some comments below.

Big Data integration of SAP Netweaver using i-OhJa

2020-05-05T12:19:53+02:00

Introduction

In this blog post I want to share some ideas and experiences with implementing a component using SAP Java Connector to easily access data and integrate non-SAP processes like data pipelines in big data clusters with the SAP Netweaver Application Server. This finally led to our solution called i-OhJa.

About two years ago we started working on a project for some customer in the financial sector. The main task was to set up a Hadoop stack as the new company wide BI platform for big data and streaming. One requirement in the migration phase was to stage load data from SAP BW (on Oracle) to Kafka, another one to load data from Kafka to BW in streaming mode. During this time Kafka streams was out of scope, so we decided to implement our dataflows in Spark streaming. This was the first project to run i-OhJa on customer side in a Spark cluster.

Prior to the project we already started evaluating SAP JCo as a library not only providing a JDBC driver for databases in a SAP Netweaver system, but being able to tightly integrate SAP and non-SAP applications in a flexible way. Our goal for i-OhJa was to implement a thin library that meets the requirements mentioned above in a highly regulated sector of financial institutions, without the need to introduce new complex infrastructures or clusters. JCo being a mighty but also basic Java library with the ability to establish a trusted and encrypted connection to SAP Netweaver systems using SNC and SSO provided by the SAP Cryptolib was the best fit for this scenario.

To be honest, the last time I implemented software in Java and J2EE using Eclipse IDE was back in 2008. After a long period mostly utilizing ABAP in SAP Netweaver based systems, I was pleased to use a more modern IDE and a functional and type safe language like Scala as our choice for developing i-OhJa. In the above-mentioned scenario, we chose to use SAP BW Open Hubs and SAP Netweaver events to get data out of BW. For the opposite direction we used Webservice DataSources to load data into BW in a streaming and real-time manner. All these interfaces are based on RFC enabled function modules and have a tight integration into the monitoring and scheduling environment of SAP BW.

EL(T)

Since there are already a bunch of ETL tools out there and as we wanted to keep i-OhJa as thin as possible, we decided to cover only the Extraction and Load of ELT. This also follows some basic ideas of modern microservice architectures. In the scenarios mentioned above this means that the data held in Kafka is a close replication of the data being transferred via OpenHub or Webservice DataSource.

Type safety and wrappers

A thing we like most about Scala besides its functional style is keeping our code type safe. A short time after starting to implement i-OhJa we decided to wrap all necessary JCo classes in Scala classes for being able to use them natively in e.g. pattern matching and collection functions and providing type safety and immutability. We provide class wrappers for function templates, function requests, function responses, tables, records/structures, record fields, all elementary types available in JCo 3.1, parameter lists, corresponding meta data classes of JCo, DDIC types, message types, selection ranges, aggregation functions, ABAP exceptions, JCo destinations, BAPI return messages, BAPI transaction commit and rollback in JCo context and more.

Code generation

With one of our customers we saw customer specific ELT frameworks written in Scala using JSON-like configuration files to define individual data pipelines. Concepts following this dynamic principle have some drawbacks:

The configuration files need to be parsed with every execution of the batch or streaming pipeline

Issues in the configuration files besides syntactic correctness lead to runtime exceptions because they bypass type checks of the compiler.

The ELT framework implementation makes heavy use of methods like asInstanceOf and isInstanceOf to cope with the vast amount of different interface data structures and types. As all the ELT logic is kept in configuration files the individual data types are known as soon as these files are being parsed, which is at runtime of the pipelines.

Using configuration files to define pipelines makes them more flexible. They can be changed and maintained without the need to change the underlying code. Therefore, the changes don’t need to be recompiled and you don’t have to follow the build and release cycle of the customer.
We consider this approach as a drawback here. Changes to configuration files are comparable to code changes bypassing all the code checks and quality gates implemented in your continuous integration processes.

Us being supporters of static type safety, we decided to take a different approach to handle the challenge of diverse data structures. We implemented Scala code generators producing case classes representing the structure of individual RFC function modules.
An example of the generated classes for a simple BAPI like BAPI_ODSO_GETLIST, delivering a list of available DSOs in a SAP BW system, would look like this:

case class JCoBapiOdsoGetlistWrapper(

    importing: JCoBapiOdsoGetlistWrapper.Importing = JCoBapiOdsoGetlistWrapper.Importing(),

    exporting: JCoBapiOdsoGetlistWrapper.Exporting = JCoBapiOdsoGetlistWrapper.Exporting(),

    changing: JCoBapiOdsoGetlistWrapper.Changing = JCoBapiOdsoGetlistWrapper.Changing(),

    tables: JCoBapiOdsoGetlistWrapper.Tables) extends JCoBapiOdsoGetlistWrapper.JCoFunctionWrapper {…}



case class Importing(objvers: Option[Char] = Some('R')) extends JCoParametersWrapper {…}



case class Exporting(`return`: Exporting.Return = Exporting.Return()) extends JCoParametersWrapper {…}

case class Changing() extends JCoParametersWrapper {…}



case class Tables(

    odsobjectlist: Seq[Tables.Odsobjectlist] = Nil,

    selodsobject: Seq[Tables.Selodsobject] = Nil,

    seltextlong: Seq[Tables.Seltextlong] = Nil) extends JCoParametersWrapper {…}



case class Return(

    `type`: Option[Char] = None,

    id: Option[String] = None,

    number: Option[String] = None,

    message: Option[String] = None,

    logNo: Option[String] = None,

    logMsgNo: Option[String] = None,

    messageV1: Option[String] = None,

    messageV2: Option[String] = None,

    messageV3: Option[String] = None,

    messageV4: Option[String] = None,

    parameter: Option[String] = None,

    row: Option[Int] = None,

    field: Option[String] = None,

    system: Option[String] = None) extends JCoRecordWrapper {…}



case class Odsobjectlist(

    odsobject: Option[String] = None,

    objvers: Option[Char] = None,

    textlong: Option[String] = None,

    objstat: Option[String] = None,

    activfl: Option[Char] = None,

    infoarea: Option[String] = None,

    odsotype: Option[Char] = None) extends JCoRecordWrapper {…}



case class Selodsobject(

    sign: Option[Char] = None,

    option: Option[String] = None,

    odsobjectlow: Option[String] = None,

    odsobjecthigh: Option[String] = None) extends JCoRecordWrapper {…}



case class Seltextlong(

    sign: Option[Char] = None,

    option: Option[String] = None,

    textlonglow: Option[String] = None,

    textlonghigh: Option[String] = None) extends JCoRecordWrapper {…}

Client and server

JCo consists of two types of library components: JCo server and JCo client. For now, it is enough to know that JCo Server will be used in cases where SAP Netweaver ABAP initiates communication (here: OpenHub scenario). Whereas JCo client is used if non-SAP applications make calls to RFCs (here: Webservice DataSource push).

BW and ODP specific client libraries

For interfaces, protocols and function libraries that are more complex than just calling one single RFC function module, it makes sense to provide specific client library modules.

We have done so for the good old BW OpenHub connections, BW BAPIs and Operational Data Provisioning. As one might expect all these interfaces are based on plain RFC functions, even ODPs as successor of the business content DataSources, which were based on ALE/IDocs.

A challenge you will face when querying data through generic interfaces like OpenHubs, BW BAPIs or ODPs serving different kind of data structures is that data is serialized as text encoded strings with a record being a concatenation of different data types in a single string. An obvious option to reconstruct data structures would be to parse these strings directly into native Java or Scala objects. We took an alternative approach by parsing the strings into wrapped JCo structures created on the fly based on the meta information we get from the corresponding function modules. This way we use JCo to convert the strings into proper data types and we can afterwards make use of all the methods provided by i-OhJa for the respective wrapper classes.

JCo allows creating JCoStructure and JCoTable objects based on JCoRecordMetaData objects. In a normal use case one would get these meta data objects by querying the repository, but in this scenario the structures need to be built at runtime by making use of the JCo.createRecordMetaData method. A challenge we faced was providing byte lengths, offsets and alignments to the JCoRecordMetaData.add methods for all the data types a field of a structure can have. i-OhJa offers the ability to calculate the byte offsets and lengths for all JCo type wrappers. Together with conversion methods for all the different DDIC and InfoObject types it can create structures and even whole JCoFunction instances based on different kind of metadata.

Reactive OpenHub server using Akka

For being able to listen for new incoming data and requests i-OhJa provides a server component with services wrapped around JCo server. Services have to extend a defined service trait and have to implement the logic for listening and processing incoming requests from a SAP system. They can also make use of the i-OhJa client libraries to request data from the SAP system. The services can be provided at runtime by registering to an i-OhJa server instance. Some predelivered services like the OpenHub extraction provide another interface for being able to register so called data adapters. The services will pass the processed data to the registered data adapter that contains the logic to finally pass or store the data. Predelivered data adapters for the OpenHub service can store data in a CSV file, output data in the console or publish data to a Kafka topic in a Kafka cluster. Further services or data adapters can be implemented according to customer specific requirements.

For being able to react fast on incoming requests, a dispatcher instance forwards requests instantly to the corresponding services. The OpenHub service uses Akka to process several OpenHub request-packages asynchronously and in parallel. A backpressure algorithm takes care of in-/decreasing the amount of data packages extracted and processed in parallel according to the resources being available.

Converters and SerDe

A typical scenario in JCo applications is to register a destination provider before using a destination object to retrieve a function object from the repository. This mutable function object contains all meta data of the corresponding RFC function module together with the state of parameter values and exceptions before and after calling the function module. In short, this object contains all the information we send to and get back from the Netweaver system using function modules.
In several cases you will have the need to serialize this object or parts of it, e.g. when sending data to Kafka or storing RFC responses for use in unit tests. Another advantage of serializing function objects is that after storing a serialized RFC response you don’t need an active SAP connection anymore to create function objects. This is an alternative to using JCo function templates, which are supported by i-OhJa too.
You can serialize a function object easily by using native Java serialization with several drawbacks, like not being able to deserialize it when upgrading JCo versions and so on. But this was only one reason for us to implement (de-)serialization using different kind of data formats.

So far, we have implemented and used converters and SerDes for the following data formats:

i-OhJa Scala wrappers and case classes from JCo Java classes:
For all the converters and SerDes implemented, i-OhJa provides implicit Scala conversion classes that just need to be imported in your application code. JCo is completely and transparently hidden behind the corresponding Scala wrappers and you do not have to worry about internal conversion and usage of JCo.

JSON:
The JSON SerDe provides lossless bidirectional serialization and deserialization holding data values and types in the same structure. We recommend the use of JSON as serialization format e.g. for RFC function templates, so you will be able to store the interface definition of common RFC enabled function modules or BAPIs provided by SAP Netweaver systems in a human readable way.

Avro 1.9.2:
Avro is widely used when it comes to serialization in big data systems like Kafka. It was our first choice for serializing data coming from SAP in the scenarios mentioned in the introduction. It supports all the data types we need like deep structures and separates the schema definition from the actual serialized data. i-OhJa can be used to apply lossless bidirectional serialization and deserialization using Avro. The generated schema definition can be used to e.g. include it in the stream of data published to Kafka, it can be stored in a AVSC file or send to a schema registry service.

Protobuf v3:
The Protobuf SerDe uses a fixed schema defined in a .proto file according to the type wrapper classes used to represent RFC requests and responses and all dependent types like records, tables and elementary types.

CSV:
The structure of CSV files only allows to store two-dimensional data like tables, so currently there is only support to serialize tables and records used in function modules in CSV files.

Spark:
Spark structured streaming uses its own schema definition defined in the package sql. Data structures can be nested deeply in objects of the class sql.Row. Spark includes all data types and schema structures necessary to convert all kind of JCo types into Spark SQL types. i-OhJa includes corresponding conversion methods, which were used when implementing the data pipelines in our customers projects.

Kafka connect:
Kafka connect defines unique schema and data objects for internal use. This allows to apply common data type converters supplied by Confluent to data streams created by diffent kind of source connectors. In a POC we implemented a flexible Kafka connect SAP Netwevaer source connector tested using the debezium embedded engine for use in the Confluent platform.

Native object serialization:
One can use native Scala and Java object serialization for the wrapper classes of i-OhJa or the POJOs that can be extracted from wrapped data.

UI

We provide two types of user interfaces for interaction with i-OhJa: A Command Line Interface and a simple server and client Web UI based on Twirl and Akka HTTP. Akka HTTP is used for building a reactive HTTP server, while Twirl allows to generate HTML pages based on native Scala code. This is an easy way to provide direct access to all kind of Scala based functionality provided by i-OhJa that is wrapped around JCo.
The following screenshots show basic web pages demonstrating possibilities to monitor and access i-OhJa.

The Server page is a simple page containing information about registered services and their RFC modules as well as running instances. In the Image shown above you can see the progress of extracting an OpenHub request.

The i-OhJa client page gives an overview of artifacts available in a connected SAP Netweaver system like RFCs, ODPs, OpenHubs and so on.

The page for a SAP BW DataStoreObject gives you an overview of the properties of a DSO and the available fields respectively InfoObjects. One can download the schema of the data in various formats or open a data preview for active data of the DSO for being able to see what the structure of the data being extracted will look like.

Testing and mocks

When it comes to unit testing of interface library functions like the ones contained in i-OhJa, we first must provide server and client mocks for being able to execute local tests without the need to establish a connection to a SAP Netweaver system. This was achieved by extending the wrapped JCo classes like JCoDestination, DestinationDataProvider, ServerDataProvider, JCoServerFactory etc.
With the mocks in place you just have to implement the behavior of the mocks based on RFC function calls. A simple scala test for the BI client method to retrieve a list of OpenHub objects available in a SAP system looks like this:

This test implementation uses a trace of an RFC call stored in a json file to retrieve the list of OpenHubs without establishing a connection to a SAP system.
For generating test data, one has basically two options:

Create a function template object and use generators like the ones from ScalaCheck to fill the parameters of the created function objects with generated values.

Trace SAP RFC function calls once, serialize and store them in object files using a SerDe and use these to replay a specific scenario locally without an active connection to a SAP system. This is the scenario we can see in the example provided above.

Side notes

Before starting to work with JCo it is worth to know that renaming the JCo-jar leads to a runtime exception because SAP doesn’t allow renaming this file:
Exception in thread "main" java.lang.ExceptionInInitializerError: JCo initialization failed with java.lang.ExceptionInInitializerError:
Illegal JCo archive "sapjco-3.1.2.jar". It is not allowed to rename or repackage the original archive "sapjco3.jar".
at com.sap.conn.jco.rt.MiddlewareJavaRfc.<clinit>(MiddlewareJavaRfc.java:165)
at com.sap.conn.jco.rt.DefaultJCoRuntime.initialize(DefaultJCoRuntime.java:78)
at com.sap.conn.jco.rt.JCoRuntimeFactory.<clinit>(JCoRuntimeFactory.java:23)
This is an issue when working with local artifactories storing artifacts using the Maven naming conventions. One workaround is to store the native libraries and the jar as a zip-file and configuring local unzipping as part of your POM. Another solution is to provide the path to the native library when starting your application using jvm parameter -Djco.library=".\sapjco-3.1.2.dll". If doing so the jar needs to be stored at the same path as the native library, but you will be able to rename it.

When running JCo in a Hortonworks HDP cluster we realized that using isDestinationDataProviderRegistered() does not lead to the expected results. This will often return false, but if you try to register a destination provider afterwards you will get a runtime exception saying that a destination provider was already registered.

An attentive reader might have noticed the default value ‘R’ for the object version in the importing parameter list of the generated code example for BAPI BAPI_ODSO_GETLIST. This seems to be a bug in JCo not being able to resolve parameter default values based on type pool constants like RS_C_OBJVERS-ACTIVE.

Summary

SAP JCo and IDoc provide basic APIs for a flexible and extensive interaction with SAP Netweaver application servers. We have implemented i-OhJa as a Scala framework for being able to use SAP JCo in a functional, typesafe and easy way. Furthermore, it simplifies accessing and transforming data transmitted via RFCs. We have successfully utilized it in a Big Data scenario using Apache Spark to integrate streaming pipelines with SAP Netweaver systems. This kind of integration is much more flexible compared to simple JDBC drivers with direct database access and allows to combine any kind of services and processes available in Java and SAP Netweaver based systems.

How to call function modules using SAP Cloud SDK for Java

2020-05-08T07:21:21+02:00

Hi All,

I am writing this blog to describe steps to build Java application calling function modules on SAP Cloud Platform CF with SAP Cloud SDK.

Function modules are on on-premise environment and called by JCo via SAP Cloud Connector.

There are so many useful information here.(2020/8/21 Added)

Architecture

System architecture is as below image, which is on the SAP Help portal.

It takes time to test this for me, since I was unfamiliar with SAP Cloud Platform services like XSUAA and App Router. To understand SAP Cloud Platform services, I posted an article about App Router, XSUAA and Java Application in Japanese.

Environment

I used both Windows and Ubuntu PC, just because my development environment is separated into Java and others. It is not mandatory to use both windows and ubuntu.

Local PC(Java development on Windows)

OS: Windows10 64-bit

openJDK: 1.8.0_242

Chocolatey: 0.10.15

maven: 3.6.3

IDE: IntelliJ IDEA Community Edition 2019.3.5

CF cli: 6.51.0+2acd15650.2020-04-07

SAP Cloud SDK for Java: 3.19.1

Local PC(App router development on Ubuntu)

OS: Ubuntu18.04.01 LTS

nvm: 0.35.3

Node.js: 12.16.2

npm: 6.14.5

SAP Cloud SDK for JavaScript:1.19.0

SAP Cloud SDK cli: 0.1.8

CF cli: 6.51.0+2acd15650.2020-04-07

Cloud Foundry

Java Buildpack version: sap java build pack 1.25.0

CF (Europe – Frankfurt)

Netweaver ABAP

NetWeaver ABAP 7.53 SP0

Cloud Connector

SAP Cloud Connector 2.11.2

Seeing following stackoverflow question, invoking function modules/ BAPIs from localhost is not supported.

What you wanna do is technically not supported: You want to invoke a BAPI from your localhost via the transport protocol RFC using the JCo library (used behind the scenes via the SAP Cloud SDK). The usage of JCo requires to run your app on SAP Cloud Platform.

https://stackoverflow.com/questions/59819607/target-host-is-not-specified-exception-while-calling-bapi-from-java-using-sap-cl

I'm not sure if invoking them is possible with Neo SDK.

when deploying locally you must add a dependency to Neo SDK (which also contains the JCO libraries).

https://answers.sap.com/questions/13012430/classnotfoundexception-when-calling-remote-functio.html?childToView=13013904#answer-13013904

Steps

1. Setup Cloud Connector

Access SAP Cloud Connector and setup connection from SAP Cloud Platform to ABAP Server. The steps are same as the one of blog post "Configure Cloud Connector for RFC connection from cloud to on-premise".

2. Create Destination

Create Destination service by CF cli command “cf create-service”. “lite” is service plan name. The steps are same as the one of blog post "Configure Cloud Connector for RFC connection from cloud to on-premise".

3. Create Routes for Java and App Router

I did this step on Ubuntu PC.

Firstly create routes for Java application and App Router by cf cli create-route command.

Please replace from <space name> to your space name. Name <host name of XXX> as you like.

cf create-route <space name> cfapps.eu10.hana.ondemand.com --hostname <host name of App Router>

cf create-route <space name> cfapps.eu10.hana.ondemand.com --hostname <host name of Java App>

4. Create Java Application

I did this step on Windows PC.

With maven, create a Java Application project.

mvn archetype:generate "-DarchetypeGroupId=com.sap.cloud.sdk.archetypes" "-DarchetypeArtifactId=scp-cf-tomee" "-DarchetypeVersion=RELEASE"

I set following information during prompt.

groupId: com.sap.cloud.sdk

artifactId: test-rfc

version: 1.0-SNAPSHOT

package: com.sap.cloud.sdk

Change "manifest.yml" file.

Add the created route in step 3 to "routers" -> "route"

Change values of "random-route"

Add the created destination to "services"

---

applications:



- name: test-rfc

  memory: 1024M

  timeout: 300

  routers:

    - route: https://<route host name>.<route domain name>

  random-route: false

  path: application/target/test-rfc-application.war

  buildpacks:

    - sap_java_buildpack

  env:

    TARGET_RUNTIME: tomee7

    SET_LOGGING_LEVEL: '{ROOT: INFO, com.sap.cloud.sdk: INFO}'

    JBP_CONFIG_SAPJVM_MEMORY_SIZES: 'metaspace:128m..'

  services:

#  - my-application-logs

  - <destination name>

#  - my-connectivity

Thought it is unusual, "Plugins Usage Analytics Maven Plugin" version 3.19.1 doesn't exist on the maven repository. So I changed the version on "<project root>/application/pom.xml". In addition, I changed skipUsageAnalytics value.

            <plugin>

                <groupId>com.sap.cloud.sdk.plugins</groupId>

                <artifactId>usage-analytics-maven-plugin</artifactId>

                <!-- changed from 3.19.1 to 3.18.0 -->

                <version>3.18.0</version>

                <executions>

                    <execution>

                        <goals>

                            <goal>usage-analytics</goal>

                        </goals>

                        <configuration>

                            <!-- changed from false to true -->

                            <skipUsageAnalytics>true</skipUsageAnalytics>

                            <generateSalt>true</generateSalt>

                            <!--

                            Note: A random salt is auto-generated once the project is built for the first time.

                            Please keep the generated salt in the POM file, for example, when pushing to git.



                            To learn more, visit: https://blogs.sap.com/2018/10/23/usage-analytics-s4sdk/

                            -->

                            <salt>55578c0d7b7bff985020ad9ce2e033dbb9bd6425acb24eb8d4b40dcc1ba0f9b0</salt>

                        </configuration>

                    </execution>

                </executions>

            </plugin>

After project generation, build and deploy the Java application.

mvn clean package && cf push

Check if the deployment is successful using Curl. Only this command run on Ubuntu PC.

$ curl https://test-rfc.cfapps.eu10.hana.ondemand.com/hello

Hello World!

5. Create XSUAA service and App Router

I did this step on Ubuntu PC.

5.1. Create App Router Project

I created App Router using SAP Cloud SDK for Javascript cli. During prompt, input Java application name "test-rfc".

It is not mandatory to use the cli. App Router and relevant codes are very simple.

$ sap-cloud-sdk add-approuter

No 'manifest.yml' found.

Enter project name as maintained in Cloud Foundry: test-rfc

  ✔ Creating files

✅ Successfully added approuter to your project.



Generated files might need customization. Documentation available here:

- xs-security.json (for help check https://help.sap.com/viewer/4505d0bdaf4948449b7f7379d24d0f0d/2.0.02/en-US/e6fc90df44464a29952e1c2c36dd9861.html)

- xs-app.json (for help check https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/c103fb414988447ead2023f768096dcc.html)

- mainfest.yml (for help check https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ba527058dc4d423a9e0a69ecc67f4593.html)

5.2. Change "xs-security.json"

Change "tenant-mode" value on "aprouter/xs-security.json" file. I have never used "shared". Please refer to tutorial and help document for further detail.

{

  "xsappname": "test-rfc",

  "tenant-mode": "dedicated"

}

5.3. Create XSUAA service

Create XSUAA service using xs-security.json by cf cli command.

cf create-service xsuaa application <xsuaa name> -c xs-security.json

bind XSUAA service and the Java application.

cf bind-service test-rfc <xsuaa name>

5.4. Create App Router

Change manifest.yml file.

applications:

  - name: test-rfc-approuter

    routes:

      - route: >-

          https://<App Router Route host name><App Router Route domain>

    path: .

    memory: 128M

    buildpacks:

      - nodejs_buildpack

    env:

#      TENANT_HOST_PATTERN: >-

#        "test-rfc-(.*).cfapps.sap.hana.ondemand.com"

      destinations: >-

        [{"name":"test-rfc","url":"https://<Java Route host name>.<Java Route domain>","forwardAuthToken":true}]

    services:

      - <xsuaa name>

Deploy the App Router.

cf push

Now go to App router route url via browser and redirect to XSUAA service. After authentication, "Hello World!" is displayed on browser.

7. Create Connectivity

I did this step on Ubuntu PC.

Create Connectivity service. The Connectivity service is necessary to connect from cloud to on-premise environment according to Help document.

cf create-service connectivity lite <connectivity name>

8. Update Java Application

I did this step on Windows PC.

Change "<project root>/manifest.yml" to bind created services. Make sure that "env" is also updated.

---

applications:



- name: test-rfc

  memory: 1024M

  timeout: 300

  random-route: false

  routers:

    - route: https://test-rfc-java.cfapps.eu10.hana.ondemand.com

  path: application/target/test-rfc-application.war

  buildpacks:

    - sap_java_buildpack

  env:

    TARGET_RUNTIME: tomee7

    SET_LOGGING_LEVEL: '{ROOT: INFO, com.sap.cloud.sdk: INFO}'

    JBP_CONFIG_SAPJVM_MEMORY_SIZES: 'metaspace:128m..'

    xsuaa_connectivity_instance_name: "<xsuaa name>"

  services:

  - <destination name>

  - <xsuaa name>

  - <connectivity name>

Create "<project root>/application/src/main/java/com/sap/cloud/sdk/RfcServlet.java". Please replace from <destination name> to your destination name. The servlet receive "name" url parameter, which is function module name. If there is no "name" parameter, "RFC PING" is called.

I haven't implemented security in this Java App, so the app can be called without App Router though it fails. I posted about the security implementation in another article, though it is in Japanese.

package com.sap.cloud.sdk;





import com.google.gson.Gson;

import com.sap.cloud.sdk.cloudplatform.connectivity.Destination;

import com.sap.cloud.sdk.cloudplatform.connectivity.DestinationAccessor;

import com.sap.cloud.sdk.s4hana.connectivity.exception.RequestExecutionException;

import com.sap.cloud.sdk.s4hana.connectivity.rfc.RfmRequest;

import com.sap.cloud.sdk.s4hana.connectivity.rfc.RfmRequestResult;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;



import javax.servlet.annotation.WebServlet;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@WebServlet("/rfc")

public class RfcServlet extends HttpServlet {

    private static final long serialVersionUID = 1L;

    private static final Logger logger = LoggerFactory.getLogger(RfcServlet.class);

    private static final Destination destinationRfc =

            DestinationAccessor.getDestination("<destination name>");



    @Override

    protected void doGet(final HttpServletRequest request, final HttpServletResponse response)

            throws IOException {



        logger.info("Start get method: " + request.getRequestURI());

        String parameter = request.getParameter("name");

        logger.info("Get parameter 'name': " + parameter);

        if (parameter == null) {

            parameter = "RFCPING";

        }

        Iterable names = destinationRfc.getPropertyNames();

        logger.info(new Gson().toJson(names));



        try {

            final RfmRequestResult rfmTest = new RfmRequest(parameter, false) //false is for non-commit

                    .execute(destinationRfc);

            response.setContentType("application/json");

            response.setCharacterEncoding("UTF-8");

            response.getWriter().write(new Gson().toJson(rfmTest));

        } catch (RequestExecutionException e) {

            e.printStackTrace();

        }

    }

}

Finally, build and deploy the Java application.

# from application directory

mvn clean package && cd .. && cf push

Result

When I open the Java Application via App router, then result is like this.

https://<App Router route host name>.<App Router route domain>/rfc?name=RFC_TEST_EXTERNAL

There are many words "Error" on the screen. but actually it is not errors. It just displays error mapping information.

If you access the app without App router, Internal Server Error occurs.

SAP Cloud SDKのRfmRequestでRFCを試す(BAPIも)

2020-05-11T11:07:53+02:00

SAP Cloud SDK for JavaでRfmRequestを使ってRFCを試してみました。メモ程度の簡単な内容ですが投稿します。

基本的なRFCのやり方は別記事「How to call function modules using SAP Cloud SDK for Java」を参照ください。

環境

SAP Cloud SDK for Java: 3.19.1

NetWeaver ABAP 7.53 SP0

Java Buildpack version: sap java build pack 1.25.0

開発内容

ABAP側RFM

いろいろなパラメータを試して見るべく、リモート呼出可能な汎用モジュールを登録。

FUNCTION y_348221_test01_rfc .

*"----------------------------------------------------------------------

*"*"ローカルインタフェース:

*"  IMPORTING

*"     VALUE(IV_NUM) TYPE  I DEFAULT 1

*"     VALUE(IS_TEST) TYPE  YS348221_TEST00 OPTIONAL

*"     VALUE(IT_TEST) TYPE  YT348221_TEST00 OPTIONAL

*"  EXPORTING

*"     VALUE(EV_NUM) TYPE  I

*"     VALUE(ES_TEST) TYPE  YS348221_TEST00

*"     VALUE(ET_TEST) TYPE  YT348221_TEST00

*"  TABLES

*"      ET_RETURN STRUCTURE  BAPIRET2 OPTIONAL

*"  CHANGING

*"     VALUE(CV_NUM) TYPE  I DEFAULT 10

*"     VALUE(CS_TEST) TYPE  YS348221_TEST00 OPTIONAL

*"     VALUE(CT_TEST) TYPE  YT348221_TEST00 OPTIONAL

*"----------------------------------------------------------------------



  ev_num = iv_num + 1.

  cv_num = cv_num + 1.



  es_test = is_test.

  es_test-yyint4 = es_test-yyint4 + 1.

  es_test-yydate = sy-datum.

  es_test-yytime = sy-uzeit.



  cs_test-yyint4 = cs_test-yyint4 + 1.

  cs_test-yydate = sy-datum + 10.

  cs_test-yytime = sy-uzeit + 10.



  APPEND es_test TO et_test.

  APPEND cs_test TO ct_test.



  DATA lt_return TYPE bapiret2_t.



  MESSAGE e001(00) WITH 'error v1' 'error v2' 'error v3' 'error v4' INTO DATA(lv_dummy).



  CALL FUNCTION 'ISU_CRM_IL_BAPIRET2_FILL'

    CHANGING

      ct_msg = lt_return.



  MESSAGE i001(00) WITH 'info v1' 'info v2' 'info v3' 'info v4' INTO lv_dummy.



  CALL FUNCTION 'ISU_CRM_IL_BAPIRET2_FILL'

    CHANGING

      ct_msg = lt_return.



  MESSAGE s001(00) WITH 'success v1' 'success v2' 'success v3' 'success v4' INTO lv_dummy.



  CALL FUNCTION 'ISU_CRM_IL_BAPIRET2_FILL'

    CHANGING

      ct_msg = lt_return.



  et_return[] = lt_return.



ENDFUNCTION.

参照する型YS348221_TEST00は構造で、いろいろなデータ型を含めたのですが、3つくらいしか試していません。時間がなかったからです。

型YT348221_TEST00は構造YT348221_TEST00のテーブルデータ型です。

Java開発

Java側のサーブレットはこんなコード。

package com.sap.cloud.sdk;



import com.google.gson.Gson;

import com.sap.cloud.sdk.cloudplatform.connectivity.Destination;

import com.sap.cloud.sdk.cloudplatform.connectivity.DestinationAccessor;

import com.sap.cloud.sdk.s4hana.connectivity.exception.RequestExecutionException;

import com.sap.cloud.sdk.s4hana.connectivity.rfc.Fields;

import com.sap.cloud.sdk.s4hana.connectivity.rfc.Table;

import com.sap.cloud.sdk.s4hana.connectivity.rfc.RfmRequest;

import com.sap.cloud.sdk.s4hana.connectivity.rfc.RfmRequestResult;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;



import javax.servlet.annotation.WebServlet;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@WebServlet("/rfc")

public class RfcServlet extends HttpServlet {

    private static final long serialVersionUID = 1L;

    private static final Logger logger = LoggerFactory.getLogger(RfcServlet.class);

    private static final Destination destinationRfc =

            DestinationAccessor.getDestination("Erp1809Rfc");



    @Override

    protected void doGet(final HttpServletRequest request, final HttpServletResponse response)

            throws IOException {



        logger.info("Start get method: " + request.getRequestURI());

        Fields inStructure = new Fields();

        inStructure.field("YYINT4", "I", 12);

        Fields exStructure = new Fields();

        Fields chStructure = new Fields();

        chStructure.field("YYINT4", "I", 4);



        try {

            RfmRequest rfmRequest = new RfmRequest("Y_348221_TEST01_RFC", false)

                    .withExporting("IV_NUM", "I", 10)

                    .withExportingFields("IS_TEST", "YS348221_TEST00", inStructure)

                    .withImporting("EV_NUM", "I", 0)

                    .withImportingFields("ES_TEST", "YS348221_TEST00", exStructure)

                    .withImportingTable("ET_TEST", "YT348221_TEST00").end()

                    .withChanging("CV_NUM", "I", 0)

                    .withChangingFields("CS_TEST", "YS348221_TEST00", chStructure)

                    .withTableAsReturn("ET_RETURN", "BAPIRET2")

                    .ignoringErrors();  //ignoringErrorsをしておかないとエラーでExceptionに行く



            Table<RfmRequest> exTable = rfmRequest.withExportingTable("IT_TEST", "YS348221_TEST00");

            exTable.row().field("YYINT4", "I", 9)

                         .field("YYCHAR10", "C", "ABC");

            Table<RfmRequest> chTable = rfmRequest.withChangingTable("CT_TEST", "YS348221_TEST00");

            chTable.row().field("YYINT4", "I", 14)

                    .field("YYCHAR10", "C", "ABCDE");



            final RfmRequestResult rfmTest = rfmRequest.execute(destinationRfc);



            response.setContentType("application/json");

            response.setCharacterEncoding("UTF-8");

            response.getWriter().write("IV_NUM: " + String.valueOf(rfmTest.get("IV_NUM")) + "\n");

            response.getWriter().write("EV_NUM: " + String.valueOf(rfmTest.get("EV_NUM")) + "\n");

            response.getWriter().write("CV_NUM: " + String.valueOf(rfmTest.get("CV_NUM")) + "\n");

            response.getWriter().write("IS_TEST: " + rfmTest.get("IS_TEST").toString() + "\n");

            response.getWriter().write("ES_TEST: " + rfmTest.get("ES_TEST").toString() + "\n");

            response.getWriter().write("CS_TEST: " + rfmTest.get("CS_TEST").toString() + "\n");

            response.getWriter().write("IS_TEST-YYINT4: " + String.valueOf(rfmTest.get("IS_TEST").getAsObject().get("YYINT4")) + "\n");

            response.getWriter().write("ES_TEST-YYINT4: " + String.valueOf(rfmTest.get("ES_TEST").getAsObject().get("YYINT4")) + "\n");

            response.getWriter().write("CS_TEST-YYINT4: " + String.valueOf(rfmTest.get("CS_TEST").getAsObject().get("YYINT4")) + "\n");

            response.getWriter().write("IT_TEST: " + rfmTest.get("IT_TEST").getAsCollection().toString() + "\n");

            response.getWriter().write("ET_TEST: " + rfmTest.get("ET_TEST").getAsCollection().toString() + "\n");

            response.getWriter().write("CT_TEST: " + rfmTest.get("CT_TEST").getAsCollection().toString() + "\n");

            response.getWriter().write("Error Message: " + rfmTest.getErrorMessages().toString() + "\n");

            response.getWriter().write("Information Message: " + rfmTest.getInformationMessages().toString() + "\n");

            response.getWriter().write("Success Message: " + rfmTest.getSuccessMessages().toString() + "\n");



        } catch (RequestExecutionException e) {

            response.setContentType("application/json");

            response.setCharacterEncoding("UTF-8");

            response.getWriter().write(new Gson().toJson(e));

            e.printStackTrace();

        }

    }

}

実行結果

呼び出したときのブラウザに表示される結果はこんな感じです。

IV_NUM: GsonResultPrimitive(jsonPrimitive=10)

EV_NUM: GsonResultPrimitive(jsonPrimitive=11)

CV_NUM: GsonResultPrimitive(jsonPrimitive=1)

IS_TEST: GsonResultObject(jsonObject={"YYINT4":12,"YYCHAR10":"","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":null,"YYTIME":"19700101 000000"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a))

ES_TEST: GsonResultObject(jsonObject={"YYINT4":13,"YYCHAR10":"","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":"20200511 000000","YYTIME":"19700101 085007"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a))

CS_TEST: GsonResultObject(jsonObject={"YYINT4":5,"YYCHAR10":"","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":"20200521 000000","YYTIME":"19700101 085017"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a))

IS_TEST-YYINT4: GsonResultPrimitive(jsonPrimitive=12)

ES_TEST-YYINT4: GsonResultPrimitive(jsonPrimitive=13)

CS_TEST-YYINT4: GsonResultPrimitive(jsonPrimitive=5)

IT_TEST: DefaultResultCollection(resultElements=[GsonResultObject(jsonObject={"YYINT4":9,"YYCHAR10":"ABC","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":null,"YYTIME":"19700101 000000"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a))])

ET_TEST: DefaultResultCollection(resultElements=[GsonResultObject(jsonObject={"YYINT4":13,"YYCHAR10":"","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":"20200511 000000","YYTIME":"19700101 085007"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a))])

CT_TEST: DefaultResultCollection(resultElements=[GsonResultObject(jsonObject={"YYINT4":14,"YYCHAR10":"ABCDE","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":null,"YYTIME":"19700101 000000"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a)), GsonResultObject(jsonObject={"YYINT4":5,"YYCHAR10":"","YYQUAN":0.00,"YYUNIT":"","YYCURR":0.00,"YYCUKY":"","YYDATE":"20200521 000000","YYTIME":"19700101 085017"}, resultElementFactory=GsonResultElementFactory(gsonBuilder=com.google.gson.GsonBuilder@2d7d1b5a))])

Error Message: [RemoteFunctionMessage(messageType=E, messageClass=00, messageNumber=001, messageText=error v1error v2error v3error v4)]

Information Message: [RemoteFunctionMessage(messageType=I, messageClass=00, messageNumber=001, messageText=info v1info v2info v3info v4)]

Success Message: [RemoteFunctionMessage(messageType=S, messageClass=00, messageNumber=001, messageText=success v1success v2success v3success v4)]

ちなみに、こんな書き方で値だけを取り出すことができます。

response.getWriter().write(rfmTest.get("RFCSI_EXPORT").getAsObject().get("RFCKERNRL").asString());

また、私がよくやる書き方のこいつをやるとエラーがよく起きます。原因をわすれてしまったのですが、構造/テーブル型のパラメータがある場合にエラーとなっている記憶があります。

response.getWriter().write(new Gson().toJson(rfmTest));

BAPIの場合(2020/7/16追加)

RFMではなく、BAPIの場合は、使うクラスこそ変わるものの使い方は大差ないです。

以下は、順にユーザロック解除、ユーザ変更BAPIを呼び出す場合です。

        final BapiRequestResult bapiResult = new BapiRequest("BAPI_USER_UNLOCK", false)

                .withExporting("USERNAME", "C", userId)  //userID becomes upper case in BAPI

                .withTableAsReturn("RETURN", "BAPIRET2")

                .execute(destinationRfc);



        logger.debug("-----------BAPI Result---------");

        logger.info(bapiResult.toString());

        logger.debug(bapiResult.getSuccessMessages().get(0).getMessageText());

        final BapiRequestResult bapiResult = new BapiRequest("BAPI_USER_CHANGE", false) //commit triggered inside bapi

                .withExporting("USERNAME", "C", userId)  //userID becomes upper case in BAPI

                .withExportingFields("PASSWORD", "BAPIPWD", password)

                .withExportingFields("PASSWORDX", "BAPIPWDX", passwordChange)

                //.withExporting("GENERATE_PWD", "C", "X")  //

                .withTableAsReturn("RETURN", "BAPIRET2")

                .execute(destinationRfc);

Connect to SAP Netweaver in a Jupyter notebook using i-OhJa

2020-05-31T22:38:21+02:00

Introduction

In this blog post I want to show how to use our solution called i-OhJa for connecting to SAP Netweaver based systems in Jupyter notebooks.
i-OhJa is a solution based on the SAP Java Connector for being able to interact with SAP Netweaver systems in the application layer. It is written in the Scala programming language and provides wrapper classes for all the basic JCo classes. In addition to that it contains SAP modules specific libraries, servers, conversion and SerDe libraries for different formats and a lot more.
In the following I will show how to use Jupyter notebooks together with i-OhJa to directly interact with an SAP Netweaver system by using the i-OhJa client library and by setting up a simple server instance for getting data in a more stream-oriented way.
Jupyter notebook is a common tool for data scientists to create and share documents, code and reports. We will use the Almond kernel here to execute Scala code directly in Jupyter notebook.

Prerequisites

Local installation and usage of python and Jupyter notebook is straight forward and well described on the web. In addition to that you need to install the Almond kernel and download the SAP Java Connector native library (.dll/.so) and Java archive (.jar) from SAP marketplace.

Client connection

i-OhJa includes a SAP BW client library and we will use it to download time tracking data from a BW DataStoreObject. At the end we will aggregate the times per person and display it in a nice and simple bar chart. This will be achieved by implementing the following steps in a Scala notebook:

Load all necessary libraries

Setting up the client connection to a SAP system

Query for time tracking data stored in a standard DSO

Aggregate the data and display it in a Vegas bar chart

Data streams

Getting data as a continuous stream from a SAP system requires to set up a server instance in the notebook itself. In the example shown here we will start a simple server instance that will listen on incoming RFCs issued by a SAP system. The RFC function we will use has a simple signature that allows to send a text together with a timestamp. This function module will be used in a simple ABAP report to send a ‘Hello World’ together with the current timestamp in a loop of 20 iterations to the running i-OhJa server instance in Jupyter.

Figure: ZHELLOWORLD RFC function module

*&---------------------------------------------------------------------*

*& Report  ZHELLOWORLD

*&

*&---------------------------------------------------------------------*

*&

*&

*&---------------------------------------------------------------------*

REPORT zhelloworld.



DATA: lv_timestamp TYPE timestampl.



DO 20 TIMES.



  GET TIME STAMP FIELD lv_timestamp.



  CALL FUNCTION 'ZHELLOWORLD' DESTINATION 'JCO_TEST'

    EXPORTING

      iv_text      = 'Hello World'

      iv_timestamp = lv_timestamp.



  WAIT UP TO 10 SECONDS.



ENDDO.

Notebook implementation

The following notebook includes the implementation for both scenarios described above.

Almond runs on Ammonite REPL that allows to load managed and unmanaged java archives during runtime. We used it to load the dependencies mentioned in the prerequisites.

Setting up a connection to a SAP system requires to provide some property values like hostname, username and password. This can be done by setting up a secured network connection and single sign on, by implementing a custom destination provider service or by simply passing the properties in the notebook itself.

As you can see in paragraph “Get DSO data” it just takes some seconds to set up the connection to the SAP system and to download a set of nearly 250.000 records. In this simple example we chose to select only two columns: personnel number and duration.

In the last paragraph of the notebook we run a server listening on "Hello World" requests and printing out the request instances in a human readable html format. Almond allows to update the output of a cell and we used this to display only the current requests of the stream. The output will be updated as soon as a new request arrive, which will be the case every 10 seconds.

Summary

Jupyter notebook together with i-OhJa provide a simple and yet powerful solution to interactively query and process data coming directly from a SAP Netweaver system. Data Scientists can make use of this solution to build rich reports and dashboards or prototypes on productive data in SAP. The i-OhJa server scenario furthermore enables to display and plot data flowing in as streams in real time.

A few code snippets while developing an ADT plugin

2020-06-05T16:20:51+02:00

Introduction

I'm busy developing a plug-in for ADT. It sends information about the currently selected class, program, function group etc. to the back-end, where some analysis is done and the results are presented.

The plug-in itself is not something that would be useful to publish, as the back-end is something useful only to my client, but I thought some snippets of how I achieved some key tasks might be helpful to others who embark on this journey.

These were developed on Eclipse 2020-03 using

ABAP Core Development Tools 3.10.2

ABAP Connectivity and Integrations Development Tools 1.120.0

Eclipse PDE 3.14.300

The backend is version 7.31 sp 17.

Connecting to the backend SAP system (on-premise)

I wanted to connect to the backend using the same credentials as the ABAP project. My application is launched in the same was as ATC, via "Run as..."

For this, I use the org.eclipse.debug.ui.launchShortcuts extension in my PDE project, with a class like this:

public class LaunchShortcut implements ILaunchShortcut {



	@Override

	public void launch(ISelection selection, String mode) {

		new myAppRunner().runFromSelection(selection);

	}



	@Override

	public void launch(IEditorPart editorPart, String mode) {

		if (editorPart instanceof MultiPageEditorPart) {

			MultiPageEditorPart editor = (MultiPageEditorPart) editorPart;

			new myAppRunner().runFromEditor(editor);

		}

	}



}

To be able to get the project credentials, I'm going to need to get some kind of project object. For the first launch method, I can get it from selection.

	public void runFromSelection(ISelection selection) {

		IProject project = ProjectUtil.getActiveAdtCoreProject(selection, null, null,

				IAdtCoreProject.ABAP_PROJECT_NATURE);

		if (project == null) {

			MessageDialog.openInformation(Display.getCurrent().getActiveShell(), "No selection",

					"No ABAP Project selected");

		} else {

   ...

...

For the second launch method it turns out that the editor (if it's some kind of ABAP editor), implements com.sap.adt.project.IProjectProvider

	public void runFromEditor(MultiPageEditorPart editor) {

		IProject project = null;

		if (editor instanceof IProjectProvider) {

			IProjectProvider projectProvider = (IProjectProvider) editor;

			project = projectProvider.getProject();

		}

		if (project == null) {

			MessageDialog.openInformation(Display.getCurrent().getActiveShell(), "No selection",

					"No ABAP Project selected");

		}

    ...

...

From the project, I can get the destination, connect via JCo, and run the RFC enabled function module.

	private void callBapi(IProject project, ArrayList<MyAppObjectStr> items) {

		try {

			String destinationId = com.sap.adt.project.AdtCoreProjectServiceFactory.createCoreProjectService()

					.getDestinationId(project);

			JCoDestination destination = JCoDestinationManager.getDestination(destinationId);



			JCoFunction function = destination.getRepository().getFunction("Z_MY_APP");

		...

 			function.execute(destination);

		...

		} catch (JCoException | PartInitException e1) {

			e1.printStackTrace();

		}

	}

Determining what I've got

This took ages. Debugging, going through the classes that make up ADT, testing, trying again and again. Until eventually, I got what I wanted without any nasty yellow (or worse red) messages coming up saying things like not an API, use discouraged - or not allowed at all.

Again, I've got the two launch shortcuts - one with an ISelection and one with an IEditorPart

selection was quite easy

if (selection instanceof ITreeSelection) {                              

	ITreeSelection treeSelection = (ITreeSelection) selection;  

	ArrayList<myObjects> items = new ArrayList<myObjects>();                                      

	for (final Iterator<?> i = treeSelection.iterator(); i.hasNext();) {                              

		Object nodeObject = i.next();                                                                 

		if (nodeObject instanceof TreeNode) {                                                         

			TreeNode node = (TreeNode) nodeObject;                                                    

			if (node.getValue() instanceof AdtObjectReference) {                                      

				AdtObjectReference value = (AdtObjectReference) node.getValue();                      

				myObject item = new myObject();                                                 

				item.name = value.getName();   // Name of the class for example                                                       

				item.type = value.getType().split("/")[0];  // CLAS/OC for example - I only want the bit before the /                                           

				items.add(item);                                                                      

			}                                                                                         

		}                                                                                

	}                                                                                                 

}

IEditorPart took me a bit longer, until i released that the concrete object that's passed to here is (I think) for every ABAP editor, an implementation of com.sap.adt.tools.core.ui.editors.IAdtFormEditor

if (editor instanceof IAdtFormEditor) {

	String objectName = editor.getTitle();

	IAdtFormEditor formEditor = (IAdtFormEditor) editor;

	String objectType = formEditor.getModel().getType();

	ArrayList<MyObject> items = new ArrayList<MyObject>();

	MyObject myObject = new MyObject();

	myObject.name = objectName.split(" ")[1]; // Splitting "SystemID ObjectName"

	myObject.type = objectType.split("/")[0]; // Splitting e.g. "CLAS/OC"

	items.add(myObject);

	...

}

Things to do

1. Ensure the "Run as myapp" option only appears when it's contextually correct

2. I'd like to run directly from a launch configuration using the org.eclipse.debug.core.launchConfigurationTypes extension in my PDE project. This would also allow me to run from the Outline of a class, for example.

public class LaunchConfigurationDelegate implements ILaunchConfigurationDelegate {



	@Override

	public void launch(ILaunchConfiguration config, String mode, ILaunch launch, IProgressMonitor monitor)

			throws CoreException {

		monitor.beginTask("Running ...", 0);

		new myAppRunner().run(config, launch);

		monitor.done();

	}



}

What I've not figured out is how to get the current object from config or launch. But I have my suspicions it'll all become clear when I get the configuration functionality installed.

3. Completely finish my app - but after 2, that's just a question of Eclipse development, not ADT!

Most irritating aspect

Obviously, it'd be lovely if we could have a fully documented set of APIs! But it doesn't have to be a stumbling block.

No, the most irritating aspect was when I couldn't debug my Java code any more. In the end I resolved it by eliminating Larry Eillison's Java, and replacing it with SAPMachine https://sap.github.io/SapMachine/. That, with a fresh install of the latest Eclipse, PDE and ADT, and everything sprang back to life.

Thanks

sebastian.ratz and armin.beil.2 of the ADT development team.

christian.drumm for his blogs on developing plugins

andreas.gautsch for the Code Insight plugin and ABAP Continuous Improvement plugin

28f4b37a40894f18a22abc696b8154f4 for the ABAP Favourites plugin

thomasalexander.ritter for his response to the blog Extensibility Ain’t Just A 13-Letter Word, by "A former member".

Data ingestion from SAP HANA cubes into SAP Analytics Cloud. Instalment 1.

2020-06-30T16:49:42+02:00

Abstract.

In this article I would like to share some insight into the data ingestion techniques from SAP HANA cubes into SAP Analytics Cloud data wranglers.

When it comes to SAP HANA the focus will be on using different SAP HANA cloud services available on SAP Cloud Platform [SCP] Cloud Foundry [CF].

In this instalment, I shall start with SAP PSA (Persistence Service) HANA service on Azure CF.

Next will follow the HaaS CF and eventually the tally will culminate with the latest HANA Cloud service on [CF].

When it comes to SAP Analytics Cloud the product features I will be making use of are described in the Feature Scope Description (FSD) document.

Let's go.

Every analytical tool has its sweet spot. SAP Analytics Cloud [SAC] supports natively direct connectivity to a number of SAP Applications as data sources. SAP HANA is one of them.

However, it has been brought to my attention that there are use cases where the live connectivity is not desirable especially with business applications that require data be fully vetted and curated at all times and where the content providers need to impose stricter controls over the data/content being delivered to the consumers.

The live SAP HANA connection has been an outspoken advantage that SAC has had over its competition.

Live or direct connectivity means not only there is no data replication but it also implies a semantic knowledge of the data source.

But, and this is maybe of a less common knowledge, with SAC one can create queries and acquire data directly from SAP HANA cubes with no ETL tool required.

(This resembles a lot the universe/query paradigm found with WebIntelligence for example.)

How is it possible ?

SAC sports a long list of so-called acquired data sources. Again, SAP HANA is one of them.

SAC is a cloud appliance sitting in its own SAP Cloud Platform [SCP] sub-account (on either Cloud Foundry or SAP Neo).

And this is where the SAP Cloud Connector [SCC] comes into the mix as it allows to leverage the cloud to on premise connectivity through the SCP connectivity service.

Question. But SCC provides the secure communication tunnel only. So what about the data itself? How do one gets connected to a data source?

Answer. That's where the SAC Cloud Agent [C4A] comes into play.

The C4A is essentially a connectivity broker - "the connection server" - a witty piece of middleware that understands the semantics of the underlying data sources.

C4A is provided as a ready-to-deploy servlet. It is best deployed on the on-premise side together with SCC.

Let's have closer look on how to acquire data from SAP HANA Service (PSA) available on SCP Cloud Foundry on Azure .

As a quick reminder all SAP HANA services on Cloud Foundry come without application runtime (no XSA). And with the exception of the PSA-based HANA service they do not offer XSC either.

That makes live connectivity a little bit more cumbersome because it implies the deployment of the HANA Analytical Adapter [HAA] which is a dedicated java application that implements the SAP Information Access (InA) REST protocol required to establish the live connectivity.

But if the data acquisition is a viable option it may help simplify the data ingestion process and help keep the cost low (by eliminating the need of using the CF application runtime for HAA deployment)

JDBC endpoint

In a nutshell, all that has to be done is to expose the jdbc SQL endpoint of the SAP HANA service.

With PSA HANA Service the jdbc SQL endpoint is already exposed on CF. However, in order to be able to use it one would need to create and bind a CF application to the service first.

This is beyond the scope of this article but if there is interest from the readers to cover this approach I might do it in one of the next episodes. so please do vote:).

Alternatively, one can use the SCC to connect to the CF sub-account where the HANA PSA-based service has been provisioned to and then create a service channel to the HANA instance.

As we have already made use of SCC to enable cloud to on premise connectivity from SAC side we shall re-use the same SCC for the service channel sake.

We can create several service channels to the same [tenant] database as depicted below.

service channels

For instance, this is how it looks like with SAP HANA Studio.

There are 3 different variants of connections definitions using two different service channels ports (30515 and 30615).

It is worth noticing is that all 3 connections point to one same tenant database (the system database is managed by SAP and cannot be accessed via the service)

SAP HANA Studio

OK. From now on one can attempt to create a SAP HANA import connection with SAC.

We shall focus on the two following options:

connect to _SYS_BIC schema and get access to the cubes there [with a "classic" database user]

connect to a HDI container and acquire data from the container's cubes [using the user access details from the service key of the HDI container service instance.]

The first option may be very convenient; when it comes to migrating from on-premise HANA development into Cloud Foundry universe.

The latter (and preferred) option allows to fully unleash the power of hardware deployment infrastructure with the focus on container shipment as opposed to package delivery.

[_SYS_BIC]

In order to demonstrate the first approach I uploaded a well known HANA SHINE package into the database.

This mimics a typical SAP HANA development paradigm where developers would work on packages that may contain a number of cubes each.

(on a side note: the data would be loaded into HANA tables either via HANA SDI engine or any other ETL tool (SAP SLT, SAP Data Services, SAP DataHub etc) - this is not in scope of this article)

Let's try to connect the dots.

Next step is with SAC and all that has to be done there is to create a new SAP HANA connection. (That may require having an administration profile granted to your SAC user.)

Once we have a working connection it is time to create a model [that will contain business information required for story telling.]

You may pick up any cube available for this connection and then build a query to further refine the data you are about to bring into SAC model.

Once your query is built you will execute it.

This will start data acquisition into a new data wrangler that will be securely kept by SAC for a period of up to 7 days:

Data wrangler

Data wrangler is an important concept. It holds the acquired data.

All the subsequent operations will be performed on the SAC tenant itself.

Data wrangler

Data model and smart discovery.

From now the data can be further curated and eventually a model will be created.

The data in the model can be periodically refreshed through scheduling.

The model can be used to build stories either manually or automatically leveraging the the smart discovery functionality.

For instance you may have decided to run a smart discovery based on Netamount measure.

SAC will then generate a story with 4 pages containing the overview, the influencers, the outliers and an interactive simulation page.

SmartDiscovery

OK. That concludes the part 1. I hope you have enjoyed reading it. Looking forward to comments.

best wishes

Piotr Tesny

PS.

In the second instalment I shall demonstrate how to import data from an HDI container (option 2 above)

SAP Cloud Foundry To On-Premise RFC Connection Using JCo

2020-07-30T12:29:06+02:00

The SAP Java Connector (SAP JCo) is a development library that enables development of SAP compatible components in Java. It can be used to communicate with on-premise SAP systems via SAP's RFC protocol.

(Source: https://support.sap.com/en/product/connectors/jco.html)

In this tutorial, we are going to learn how can we call a function module in an on-premise ABAP system by SAP JCo (Inbound).

Let’s go step by step.

Step 1: As a starting point, I build a maven web project with the following code:

package com.test.jco;



import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.ServletException;

import javax.servlet.annotation.WebServlet;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;



 

import com.sap.conn.jco.JCoDestination;

import com.sap.conn.jco.JCoDestinationManager;

import com.sap.conn.jco.JCoFunction;

import com.sap.conn.jco.JCoParameterList;

import com.sap.conn.jco.JCoRepository;



 

@WebServlet("/ConnectRFC/*")



public class ConnectRFC extends HttpServlet {



    private static final long serialVersionUID = 1L;



    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {



        PrintWriter responseWriter = response.getWriter();



        try {



            // access the RFC Destination "Test"

            JCoDestination destination = JCoDestinationManager.getDestination("Test");



            // make an invocation of STFC_CONNECTION in the backend

            JCoRepository repo = destination.getRepository();

            JCoFunction stfcConnection = repo.getFunction("STFC_CONNECTION");



            JCoParameterList imports = stfcConnection.getImportParameterList();

            imports.setValue("REQUTEXT", "JCO successful");



            stfcConnection.execute(destination);



            JCoParameterList exports = stfcConnection.getExportParameterList();

            String echotext = exports.getString("ECHOTEXT");

            String resptext = exports.getString("RESPTEXT");



            responseWriter.println(echotext+":"+resptext);

        } catch (Exception e) {



            e.printStackTrace();



        }



    }



}

The explanation goes as follows:

"Test" is the name of the destination which will be used after a few steps.

"STFC_CONNECTION" is a standard ABAP function module, which I am using here to test the connectivity.

Following JCo dependency needs to be included in your project.

<dependencies>

  <dependency>

    <groupId>com.sap.cloud</groupId>

    <artifactId>neo-java-web-api</artifactId>

    <version>[3.71.8,4.0.0)</version>

    <scope>provided</scope>

  </dependency>

</dependencies>

Step 2: Now we need to log into the SAP CF subaccount, where we want to deploy our application. Here we need to create and bind instances for the following three services:
- Connectivity Service
- Destination Service
- XSUAA service

I have created these service instances and named them as following - jco_con , jco_dest, and jco_xs. Select the service plan as application and Provide the following configuration in parameters while creating xsuaa instance. Here "connect-rfc" is the app name by which I will deploy my java application in CF.

{

    "xsappname" : "connect-rfc",

    "tenant-mode": "dedicated",

    "scopes": [

        {

            "name": "$XSAPPNAME.all",

            "description": "all"

        }

    ]

}

Step 3: Now deploy the war file to the subaccount with the following manifest.yml configuration.

---



applications:



 



- name: connect-rfc



  buildpacks:



  - sap_java_buildpack



  env:



    SAP_JWT_TRUST_ACL: '[{"clientid":"*","identityzone":"*"}]'



    xsuaa_connectivity_instance_name: "jco_xs"



  services:



    - jco_xs



    - jco_con



    - jco_dest

Step 4: Create a node (approuter ) ** . Make necessary arrangements into xs-app.json (Point the URL to the destination). Finally, Deploy this in the subaccount with the following manifest.yml configuration.
```
---



applications:



 



- name: approuter-jco



  path: ./



  buildpacks:



  - nodejs_buildpack



  memory: 120M



  env:



    NODE_TLS_REJECT_UNAUTHORIZED: 0



    destinations: >



      [



         {"name":"dest", "url" :"https://<your java application url>/ConnectRFC", "forwardAuthToken": true }



      ]



  services:



    - jco_xs
```
When choosing the application route, you are requested to login. Provide the credentials known by the IdP you configured in Roles & Trust. After successful login, you are routed to the java application which is then executed. It prompts an error that destination "Test" does not exist, which is obvious as we didn't create a destination till now.

Step 5: Create an RFC destination named "Test" in your destination instance.

Step 6: Configure the system mapping and the function module in the Cloud Connector. Provide access to the function module "STFC_CONNECTION".

cloud connector

SAP Cloud Platform - CF

Step 7: Run approuter, provide the credentials. This time you will receive the output of your Servlet. I received the following output.

JCO successful:SAP R/3 Rel. 752   Sysid: XXX      Date: 20200725   Time: 110012   Logon_Data: 100/XXXX/E

Note : In this tutorial, I used approuter for authentication purpose. You can use AppToAppSSO to propagate authentication token. Token is required for On-Premise connectivity.

**Follow the steps in Application Router or use the demo file approuter.zip (download).

With this, I would like to conclude the tutorial. For more details, follow the below links :

https://support.sap.com/en/product/connectors/jco.html

https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/e54cc8fbbb571014beb5caaf6aa31280.html

https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/7e306250e08340f89d6c103e28840f30.html

Analytics Agent on Paraya Glassfish

2020-09-15T11:06:12+02:00

The SAP Analytics Agent is intended to connect on Premise Systems via the Cloud Connector to SAP Analytics cloud.

The agent itself comes as a war file deployable for Apache Tomcat servers.

DISCLAIMER: This is an experimental setup. It is NOT SUPPORTED and should not be used in a productive environment.

Despite Tomcat being the most widely used Java application server I recently came across an environment where Tomcat was not available but Glassfish was the Java Server of choice. In this blog I would like to share the results of my experiments.

TL;DR

The Analytics Agent seems to be running fine on Glassfish too. Only simple queries were used in my experiments - so this is still a very weak statement.

For this tutorial we need:

A SAC tennant where we have admin rights

An SAP JCO Adapter Version 3 SF 20 - search for Java Connector at https://launchpad.support.sap.com/#/softwarecenter

An up and running SAP Cloud Connector with access to the internet

The Analytics Agent war file (search via the link above for "analytics agent") - SAP Analytics Cloud Agent 1.0.83 was used here.

The Paraya Glassfish 5 Web Application Server (Community Edition) - download via their website

A backend system (here we use BW/4)

First we download and install the Paraya Glassfish community edition.

I will install it on my local machine on Windows 10 which is pretty much just unzipping it to a folder on my local harddrive. I have created a folder \paraya5

Then we copy the JCO files to the Paraya \lib folder payara5\glassfish\lib

and start the server via payara5\glassfish\asadmin.bat

I've had a bit of an issue with my JDK not being picked up - so I made some changes to the config of glassfish payara5\\glassfish\config\asenv.bat to specifically point to the intended JDK.

set AS_JAVA=C:\Program Files\Java\jdk-11

After starting the Glassfish we can reach the admin console via the URL : http://127.0.0.1:4848

No admin password is required in the default setup.

Then we deploy the Analytics Agent war file via Applications-> Deploy or the direct link

The Analytics Agent will start and be available via http://127.0.0.1:8080

Then we need to create an Analytics Agent user to be able to access the just deployed application. We go back to the command line where we started the Paraya Server using asadmin.bat

In the admin console we enter:

asamin> create-file-user --groups Services user1

This will create a user: user1 that belongs to the group "Services" then we will be prompted to create a password we will need later

We switch back to the SAC Tennant.

I assume that this is the first CloudConnector connected to SAC

We go to System->Administration->Datasource Configuration

We need to enable CC Connections to the tenant by activating the SAP CP Account. I have added my email address and subsequently the Subaccount number can be seen.

We copy this number and go next to our Cloud Connector administration.

Here we create a new connection to our SAC Tennant. The quired information can be taken from the previous step in the SAC Tennant. Just make sure that your Subaccount user has the Cloud Connector Admin role.

Next we add the connection details to our Glassfish server. I have both the Cloud Connector and Glassfish running on the same machine: So this gives the following configuration:

Make sure to add the URL Path /C4_AGENT/ to the Resources (Path+AllSubPath - see Arrow) or you will get an "access denied" entry in you CC Log files.

As the next step we go back to the SAC Tennant:

To System->Administration->Datasource Configuration and add an onPremise Datasource

In the Cloud Connector we have configured the "Virtual Host" to be 127.0.0.1 Port 8080 and this is the information we put here.

The user + password is for the Analytics Agent and was previously configured by us via the Glassfish Admin Console (user1 + password)

So we have all the required information to fill in the details for the Default Location:

To configure the connection to the BW/4 System is the last part and is surprisingly done via SAC and not within the Analytics Agent.

We go to System-> Connection and add a new Connection:

We add the system details and our BW/4 login credentials (we need the SID, System Number, Client ID, Application Server URL, User Credentials)

The server URL needs to be accessible from the Analytics Agent, make sure that no Firewall is blocking the agent from accessing the BW/4 system. There is no need to open the BW/4 system to the internet.

Finally we can create a new Model based on the just created Data Connection:

GetDataFromSource-> BW/4 and then we select the just created Connection.

From there we can use the model and create a story based on it.

RFC Gateway security, part 1 - basic understanding

2021-01-26T09:05:26+01:00

From my experience the RFC Gateway security is for many SAP Administrators still a not well understood topic. As a result many SAP systems lack for example of proper defined ACLs to prevent malicious use of the RFC Gateway.

After an attack vector was published in the talk "SAP Gateway to Heaven" from Mathieu Geli and Dmitry Chastuhin at OPDCA 2019 Dubai (https://github.com/gelim/sap_ms) the RFC Gateway security is even more important than ever. This publication got considerable public attention as 10KBLAZE.

With this blogpost series i try to give a comprehensive explanation of the RFC Gateway Security:

Part 1: General questions about the RFC Gateway and RFC Gateway security.
Part 2: reginfo ACL in detail.
Part 3: secinfo ACL in detail.
Part 4: prxyinfo ACL in detail.
Part 5: Security considerations related to these ACLs.
Part 6: RFC Gateway Logging.
Part 7: Secure communication
Part 8: OS command execution using sapxpg
Part 9: enhanced security for sapxpg

Updates:

2023-11-15: Added usage type 'extern-to-extern RFC communication with JCo 3.x'
2023-03-21: Added Part 9: enhanced security for sapxpg
2023-02-28: Added Part 8: OS command execution using sapxpg
2021-11-10: Added Part 7: Secure communication

Basic understanding

In the following i will do the question and answer game to develop a basic understanding of the RFC Gateway, the RFC Gateway security and its related terms.

What is the RFC Gateway?

The RFC Gateway can be seen as a communication middleware. The RFC Gateway act as an RFC Server which enables RFC function modules to be used by RFC clients. It also enables communication between work or server processes of SAP NetWeaver AS and external programs.

From a technical perspective the RFC Gateway is a SAP kernel process (gwrd, gwrd.exe) running on OS level as user <sapsid>adm.

Where can we find the RFC Gateway?

There are three places where we can find an RFC Gateway:

- In SAP NetWeaver Application Server ABAP: Every Application Server has a built-in RFC Gateway.
- In SAP NetWeaver Application Server Java: The SCS instance has a built-in RFC Gateway.
- The Stand-alone RFC Gateway: As a dedicated RFC Gateway serving for various RFC clients or as an additional component which may be used to extend a SAP NW AS ABAP or AS Java system.

Who can access the RFC Gateway in general

The RFC Gateway is by default reachable via the services 'sapgw<InstNo>' and 'sapgw<InstNo>s' which can be mapped to the ports '33<InstNo>' and '48<InstNo>'. Access to this ports is typically restricted on network level.

There may also be an ACL in place which controls access on application level. The location of this ACL can be defined by parameter 'gw/acl_file'.

Which usage types are there?

This diagram shows all use-cases except `Proxy to other RFC Gateways´. The subsequent blogs of will describe each individually.

'Registered external RFC Servers'

The RFC Gateway allows 'external RFC Server programs' (also known as 'Registered Server' or 'Registered Server Program') to register to itself and allows RFC clients to consume the functions offered by these programs.

An example would be 'Trex_<SID>_<timestamp>' registered at the RFC Gateway of the SAP NW AS ABAP from the server running SAP TREX and consumed by the same AS ABAP as an RFC client.

Another example would be 'IGS.<SID>' of SAP IGS registered at the RFC Gateway of the SAP NW AS ABAP from the same server as AS ABAP (since it is also part of it) and consumed by the same AS ABAP as an RFC client.

'Started external RFC Servers'

The RFC Gateway is capable to start programs on the OS level.

Common examples are the program 'tp' for transport management via STMS started on the RFC Gateway host of AS ABAP or the program 'gnetx.exe' for the graphical screen painter started on the SAP GUI client host.

While typically remote servers start the to-be-registered program on the OS level by themselves, there may be cases where starting a program is used to register a 'Registered Server Program' at the RFC Gateway. In these cases the program started by the RFC Gateway may also be the program which tries to register to the same RFC Gateway.

Please note: One should be aware that starting a program using the RFC Gateway is an interactive task. This means the call of a program is always waiting for an answer before it times out. If the called program is not an RFC enabled program (compiled with the SAP RFC library) the call will time out, but the program is still left running on the OS level!
To overcome this issue the RFC enabled program 'SAPXPG' can be used as a wrapper to call any OS command. This is for example used by AS ABAP when starting external commands using transaction SM49/SM69.

'RFC destinations'

Most common use-case is the SAP-to-SAP communication, in other words communication via RFC connections between SAP NetWeaver AS systems, but also communication from RFC clients using the SAP Java Connector (JCo) or the SAP .NET Connector (NCo) to SAP NetWeaver systems.

The RFC Gateway hands over the request from the RFC client to the dispatcher which assigns it to a work process (AS ABAP) or to a server process (AS Java).

'Proxy to other RFC Gateways'

The RFC Gateway can be used to proxy requests to other RFC Gateways.

'extern-to-extern RFC communication with JCo 3.x'

As of JCo 3.0.10, there is also a use-case where a JCo based RFC Client communicates via the RFC Gateway with a JCo based registered external RFC server.

Please note: For security reasons, this usage type is not recommended. For more details, see SAP Note 1877907.

What about the reginfo ACL?

The reginfo file is holding rules controlling which remote servers (based on their hostname/ip-address) are allowed to either register, access or cancel which 'Registered Server Programs' (based on their program alias (also known as 'TP name')).

Its location is defined by parameter 'gw/reg_info'.
In case of AS ABAP for example it may be defined as '$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_REG_INFO)' to make sure all RFC Gateways of the application servers of the same system relay on the same configuration.

What about the secinfo ACL?

The secinfo file is holding rules controlling which programs (based on their executable name or fullpath, if not in $PATH) can be started by which user calling from which host(s) (based on its hostname/ip-address) on which RFC Gateway server(s) (based on their hostname/ip-address).

Its location is defined by parameter 'gw/sec_info'.
In case of AS ABAP for example it may be defined as '$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_SEC_INFO)' to make sure all RFC Gateways of the application servers of the same system relay on the same configuration.

How are reginfo and secinfo related?

As we learnt before the reginfo and secinfo are defining rules for very different use-cases, so they are not related.

What about the prxyinfo ACL?

The prxyinfo file is holding rules controlling which source systems (based on their hostname/ip-address) are allowed to talk to which destination systems (based on their hostname/ip-address) over the current RFC Gateway.

Its location is defined by parameter 'gw/prxy_info'.
In case of AS ABAP for example it may be defined as '$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_PRXY_INFO)' to make sure all RFC Gateways of the application servers of the same system relay on the same configuration.

What about the SNC System ACL?

RFCs between two SAP NetWeaver AS ABAP systems are typically controlled on network level only. The RFC Gateway does not perform any additional security checks.

When using SNC to secure RFC destinations on AS ABAP the so called 'SNC System ACL', also known as 'System Authentication', is introduced and must be maintained accordingly.

This ACL is applied on the ABAP layer and is maintained in transaction SNC0.

Please note: 'SNC System ACL' is not a feature of the RFC Gateway itself.

What about the SNC User ACL?

RFCs between RFC clients using JCo/NCo or Registered Server Programs and the AS ABAP are typically controlled on network level only. The RFC Gateway does not perform any additional security checks.

When using SNC to secure logon for RFC Clients or Registered Server Programs the so called 'Extended SNC Access Control List (ACL) for Users', also known as 'User Authentication', is introduced. With this, the AS ABAP verifies whether the RFC client is allowed to logon with the combination of username and SNC name sent in the connection attempt. The SNC name taken from the X.509 client certificate is used for the authentication in favor of password based logon.

This Extended SNC ACL for Users is applied on the ABAP layer and is maintained in table USRACLEXT, for example using transaction SM30.

The mapping of an SNC name to a user can also be done in transaction SU01. Keep in mind that in SU01 only a 1:1 mapping can be performed while in the table USRACLEXT more than one certificates can be mapped to one user.

Please note: 'SNC User ACL' is not a feature of the RFC Gateway itself.

Next -->

SAP Build Apps and BAPIs: RFC meets Web

2023-04-02T12:17:56+02:00

"RFC meets Web"

Enable all your RFC functions for web consumption without development?

Today, I'm excited to share a new thing: A proxy on SAP BTP that translates from REST to SAP RFC calls, making it possible to use BAPIs and RFC-enabled function modules on older SAP ECC or S/4HANA systems.

This solution is particularly useful for SAP ERP users who are looking to integrate with systems that lack the new OData APIs that are only available on newer S/4HANA systems. With the REST-to-RFC proxy, RFC meets web, creating a seamless integration experience that unlocks the full potential of your SAP ecosystem.

Benefits:

Protect your past investment: Use your function modules for the web

RFC modules turned into synchronous REST APIs

No further development work

Secured communication through SAP BTP destinations

Image 1: Outline of solution - it works with any RFC function module (Y/Z-RFC modules included)

In this blog post, we'll take a closer look at how this proxy works, the benefits it provides, and the impact it can have on your SAP integration projects. So, let's dive in and discover the possibilities of web meets RFC!

Solution approach

SAP BTP offers the destination service to define ways to connect to systems. Keeping destinations separate from applications makes them reusable and easy to maintain. They come in several flavors like:

HTTP - for anything like REST, OData-REST, HTML and the like.

LDAP - Lightweight Directory Access Protocol to lookup information in a network. Often used for organizational data of entities and persons.

MAIL - to send emails to an SMTP server

RFC - Remote Function Call, this is what we look at for the cloud connector-facing side.

From here we define the first destination to the cloud connector (CC) as RFC. You need to white-list the function modules you plan to use in your cloud connector instance.

Image 2: Example of an RFC destination. The ashost is as defined in your CC.

I use this destination in the Java HTTPServlet. On the consumption side you'll need another destination that you can use for e.g. SAP Build Apps and which is provided by the HTTPServlet. If you secure it with OAuth2 the config could look like that.

Image 3: REST destination for consumption of BAPIs or RFC functions in general.

Since I use xsuaa for authentication and authorization I've defined 2 scopes to allow for display and change authorization.

Image 4: POST and GET related scopes to be assigned to relevant users for consumption.

The difference between the two is that the POST will trigger a BAPI.commit and therefore posts data in your S/4HANA or ECC system while the GET doesn't. Of course it depends on how you've designed your ABAP code - standard BAPIs will adhere to this approach.

SAP Build Apps demo: Change material master

Enough talk! Let's see a demo built with SAP Build Apps. It uses 3 BAPIs:

BAPI_MATERIAL_GETLIST - To search for materials and get them in a list

BAPI_MATERIAL_GETALL - To retrieve the details of a selected material

BAPI_MATERIAL_SAVEDATA - To change some fields in the material master

There is no development done on both backend and frontend.

1. Mobile application

2. SAP Build and S/4HANA Backend

Solution Architecture

Below are the schematics for using the REST to RFC proxy running on BTP Cloud Foundry.

Image 2: Solution architecture for REST-RFC proxy on SAP BTP Cloud Foundry

I'll explain the technical details in a second blog if you are interested to create such a proxy on BTP for yourself.

Conclusion

And there it is: A proxy that opens all your RFC developments to the web in a secured manner. Hope it is useful!

Check my second blog for the technical details on how you can design the proxy on SAP BTP.

Calling a SAP PI/PO RFC integration from Java with JCo Library

2023-09-14T01:24:37+02:00

Hello everyone,

We needed to call SAP PI/PO RFC integration with Java according to a customer's need. I was able to call functions from SAP using JCo before, but I had not worked on triggering the SAP PI/PO RFC sender. After some research, I found out how to do it and I wanted to share it with you.

Before we write our Java code, we have a small but necessary step to do.

First of all, you need to download the JCo driver for your operating system. It is important to review the installation.html page located in the javadoc folder in the driver archive you downloaded. Actions to be taken according to your operating system are written on the HTML page. (SAP JCo Page)

You need to add "jco.allow_non_abap_partner" parameter to the VM parameter of SAP PI/PO instance. You can review this SNote showing how to add a parameter. (1729203 - Support for communication with external RFC server)

Next step is create a RFC sender channel. You can create a standart RFC sender channel. But you have to enable Advanced Mode. Also you need to unchecked Verify Sender System parameter.

My channel looks like;

Also we need to create an RFC integration. I imported a function to ESR from SAP which I will call from Java.

Then I created an ICO with that function.

If everything is okay, let's start!

First, we need to define SAP.jcoDestination file for Repository. You can fill this template with your SAP system information for SAP.jcoDestination file.

jco.client.ashost=sap_application_server_host

jco.client.sysnr=sap_system_number

jco.client.client=sap_system_client_number

jco.client.user=sap_user

jco.client.passwd=sap_user_password

jco.client.lang=sap_language

Then, we have to create SAP_PO.jcoDestination file for communicate with SAP PI/PO. You can fill this template with your PO system information for SAP_PO.jcoDestination file.

jco.client.type=E

jco.client.gwhost=your_po_host

jco.client.gwserv=your_po_gateway

jco.client.tpname=PO_RFC_SND

jco.destination.repository_destination=repository_file_name

The jco.client.tpname parameter represents the Program ID parameter on the RFC sender channel. I write PO_RFC_SND to the value of this parameter because I write PO_RFC_SND to the Program ID value in the RFC channel.

The value of jco.destination.repository_destination parameter must be SAP Repository file name. We defined the name of the file as SAP.jcoDestination in this blog. Therefore, we write SAP to the value of the jco.destination.repository_destination parameter.

After the files are created, your project folder should look like this. (The .jcoDestination files must be in the same place as your project. )

Let's code!

First, you have to add sapjco3.jar as external library to your project. If you done, you can continue next step.

Define a JCoDestination variable. We have to write SAP_PO in getDestination method. Because our PO destination configuration file name is SAP_PO.jcoDestination. (If you named the file differently, use the name you typed. Don't forget! The file extension must be .jcoDestination. )

JCoDestination dest = JCoDestinationManager.getDestination("SAP_PO");

We have to define JCoFunction variable. After that, we will use getFunction method with function name which we want to call. I will use "RFC_FUNCTION_SEARCH" function.

JCoFunction function = dest.getRepository().getFunction("RFC_FUNCTION_SEARCH");

Now, we need to set import parameters of RFC_FUNCTION_SEARCH function. You can see parameters of the function with SE37 tcode in SAP system.

I can see only FUNCNAME parameter is mandatory. I want to get all Z* named functions from SAP system therefore I assigned "Z*" to the FUNCNAME parameter.

function.getImportParameterList().setValue("FUNCNAME","Z*");

I am running the function.

function.execute(dest);

If you want to get result after execute the function, you can do with below code.

String result = function.getTableParameterList().toJSON();

System.out.println(result);

Result;

package com.example;



import com.sap.conn.jco.JCoDestination;

import com.sap.conn.jco.JCoDestinationManager;

import com.sap.conn.jco.JCoException;

import com.sap.conn.jco.JCoFunction;



import java.io.IOException;

public class Main {



	public static void main(String[] args) throws IOException, JCoException {



		// Define a JCoDestination variable. We have to write SAP_PO in getDestination method.

		// Because our PO destination configuration file name is SAP_PO.jcoDestination.

		// (If you named the file differently, use the name you typed. Don't forget! The file extension must be .jcoDestination. )

		JCoDestination dest = JCoDestinationManager.getDestination("SAP_PO");



		//We can define the function which we want to call. I will use "RFC_FUNCTION_SEARCH" function.

		JCoFunction function  = dest.getRepository().getFunction("RFC_FUNCTION_SEARCH");



		//Now, we need to set import parameters of RFC_FUNCTION_SEARCH function.

		// You can see parameters of the function with SE37 tcode in SAP system.

		function.getImportParameterList().setValue("FUNCNAME","Z*");



		//Execute the function

		function.execute(dest);



		//Print result

		String result = function.getTableParameterList().toJSON();

		System.out.println(result);



	}



}

When you call the RFC with Java, you can see the message in Message Monitor.

Conclusion

In summary, with this blog you can call the RFC integrations you developed in PI/PO with Java using the JCO library. In addition, based on this example, you can also call the function from SAP without PI/PO. You can use the SimpleCall.java example in the JCO file you downloaded.

Thank you for reading.

Import Data Connection to SAP S/4HANA in SAP Analytics Cloud : Technical Configuration

2024-05-10T12:04:30.942000+02:00

In this blog we’ll discuss complete steps for Import data connection from S/4 hana on-premise system to SAP Analytics Cloud . The Operating system we are using on which S/4 Hana system is installed is SUSE Linux SP 15.

Here, Our Data source is S/4 Hana from which the SAP Analytics Cloud is connected using the SAP Analytics Cloud Agent and SAP Cloud Connector.

It is recommended that the Cloud Connector, SAP Analytics Cloud agent, and the SAP Java Connector (JCo) are installed together on a dedicated server, and not a personal computer. This helps to ensure that multiple users can use an import data connection without experiencing slowness or downtime.

The SAP Analytics Cloud Agent Simple Deployment Kit allows you to quickly get your import data connections working.

The simple deployment kit is only supported on Windows 64-bit operating systems. If you have a different server, such as Linux, you'll need to install and configure the agent manually.

If we have windows Environment, then the SAP Analytics Cloud Agent Simple Deployment Kit is preferred. More details can be found in the below link.

SAP Analytics Cloud Agent Simple Deployment Kit | SAP Help Portal

For Linux Environment we have to install SAP JVM, SAP Cloud Connector, Tomcat Apache server, SAC Agent, Java Connector.

Below are the steps for Import Data connection for On-premise S/4 HANA systems -

SAP JVM 8.1 and JDK installation on the linux server
Install SAP Cloud Connector on the same linux server.
Installing Tomcat Apache server
Installing and configuring Java connector (Jco)in Tomcat .
Installing and configuring SAP Analytics Cloud Agent .
Configuration and Connection steps in SAC portal

1. SAP JVM 8.1 installation on the same linux server

Download the SAP JVM from the below link:

https://tools.hana.ondemand.com/#cloud

Download the rpm file compatible for linux 86x64 -
sapjvm-8.1.095-linux-x64.rpm (sha1)

Move the file to the server and run the below command to install SAP JVM

rpm -i <file_name>.rpm

Also it is recommended to install the openjdk packages on SUSE linux .

Run command ‘zypper install java’

To check the verison of openjdk installed.

Run command 'java –version'

2. Install SAP Cloud Connector on the same linux server.

To download the SAP Cloud Connector go to the below link :

https://tools.hana.ondemand.com/#cloud

Download the zip file for Linux x86_64 Architechture and move the downloaded file to the server.

Now, unzip the file and install the rpm package for cloud connector as below.

Cloud connector is installed now.

To open the SCC, enter: https://<hostname>:8443 in a browser, where the <hostname> is the hostname of the machine on which the connector is installed, and the port number is the one configured during installation. The default port number is 8443

By default Login Credentials are :

Username : Administrator

Password : manage

After the fist login , It prompts you to change password for the Administrator User.

Now Add the SAC subaccount to the cloud connector:

Click on “Add subaccount” and enter the details SAC subaccount , which you can find on SAP Analytics Cloud.

To find the Subaccount details of SAP Analytics Cloud :

You must use a System Owner account to perform the following steps. If you don't know who the system owner is, log on to SAP Analytics Cloud and from the side navigation, choose Security > Users.

Log on to SAP Analytics Cloud.
From the side navigation, choose System > Administration.
Switch to the Data Source Configuration tab.

3.Installing Tomcat Apache Server :

Create a directory named tomcat in the /opt folder:
Go to the Apache Tomcat 8 Download page by clicking this https://tomcat.apache.org/download-80.cgi Place your cursor under 8.5.65 Binary Distributions, right-click on the tar file and select the copy link address from the menu that appears (as shown in the picture below). At the time of writing, Tomcat 8 is the most recent edition, but you are free to use whatever version is most current.

Download the file from wget

Extract the tar.gz file

Starting Tomcat apache server

4.Installing and configuring Java connector (Jco)in Tomcat .

Download SAP Java connector from SAP support portal -> Software downloads

On a Linux server, put the sapjco3.jar and libsapjco3.so in the lib folder of Apache Tomcat.

5. Installing and configuring SAP Analytics Cloud Agent .

It is recommended, but not mandatory, that the Cloud Connector, SAP Analytics Cloud agent, and the SAP JCO are installed together on a dedicated server, and not a personal computer. This helps to ensure that multiple users can use an import data connection without experiencing slowness or downtime.

Modifying the Cloud Connector’s embedded web application and deploying the agent to it is not supported.

Download the SAP Analytics Cloud agent from the SAP Support Portal.

The agent is available on the SAP Software Downloads page. Expand By Category, select SAP Cloud Solutions > SAP ANALYTICS CLOUD CONN > SAP ANALYTICS CLOUD CONN 1.0 > SAP ANALYTICS CLOUD AGENT 1.0 and download the latest version.

Unzip the downloaded file and rename the WAR file to C4A_AGENT.war.
Extract the package and copy the file C4A_AGENT.war to your Tomcat webapps directory.

The agent will automatically deploy when Tomcat is restarted.

Create a user for the SAP Analytics Cloud agent and assign the Services role to the user.

The user credentials will be needed later for setting up the connection to SAP Analytics Cloud.

Restart the Tomcat application server for the settings to take effect.
Test if the installation was successful, by opening the following URL in your browser: http://<Host>:<Port>/C4A_AGENT/deploymentInfo

The version of the SAP Analytics Cloud agent installed is displayed.

6. Configuration and Connection steps in SAC portal

Add the Data source in System > Administration > on-premise data sources

Check connection configuration , It should be green.

From the side navigation, choose

Connections > (Add Connection).

The Select a data source dialog will appear.

Expand Acquire Data and select SAP S/4HANA.
In the New SAP S/4HANA Connection dialog, do the following:

In the Connection Information section, add a Connection Name and Description.
If you are connecting to an SAP S/4HANA on-premise system, select Connect to an On-Premise OData service, and then select the Location of your Cloud Connector from the list.
Enter the Data Service URL published during your configuration

Select the authentication type.
Enter the User Name and Password of the user you want to import data from.
Choose Create.

The new connection is added to the list of connections on the Connections screen.

Conclusion :

Import Data Connection to S/4Hana on-premise system in SAP Analytics Cloud has been established successfully.

SAP Community - SAP Java Connector (JCo)

SAP UI和Salesforce UI开发漫谈

SAP UI

SAP GUI + Dynpro

Web Dynpro

BSP/CRM WebClient UI

SAP UI5/Fiori

UI5 In SAP Cloud for Customer(C4C)

Hybris Enterprise Commerce Platform(ECP)

用JavaScript访问SAP云平台上的服务遇到跨域问题该怎么办

解法1：Cross-Origin Resource Sharing

解法2：JSONP

解法3：自开发ProxyServlet

更多阅读

Calling BAPIs in the SAP S/4HANA Public Cloud

Introduction

About this series

Some background

BAPIs in SAP S/4HANA Cloud – When And How To Use Them

My Test Cases

Important Reminder

Preparation

What I used

Helpful Knowledge

Quick Guide to set up the Cloud Connector

Step List

Preparing the SAP S/4 HANA Cloud System

Calling a BAPI in the SAP S/4HANA Cloud from a non-SAP system

Introduction

Calling a BAPI in the Cloud from non-SAP systems ( e.g. a JAVA program)

Preparation

What I used

What I did

Setting up Eclipse

JCO Destination File

Sample Program

Conclusion

What I learned from this test case

Your Feedback

What’s next

SAP Hana XSA Code Jam en Ciudad de Mexico ?? 2019

Es un evento GRATUITO, pero como es un evento práctico tiene ciertos requerimientos para poder participar

Debes traer tu propia computadora portátil) y de preferencia q tengas #HANA #Express instalado

La ponencia estará dictada por la catedrática lsubatin de @SAP, experta en la materia, que estará en el sitio para responder a sus preguntas y compartir información y consejos relevantes.

If you are a SAP programmer, who seeks to know or update,

Made your pre-register ASAP

Sponsors

Important Facts

CONTACT

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector - Part 1/3

Introduction

Use case

What are my options?

What about standard SAP and third party enterprise products?

Disclaimer

What am I going to do?

Versions

Source code

Blog links

Architecture

Setup a demo NW system in SAP CAL

SAP Cloud Appliance Library (CAL)

Cost

Tips

Amazon AWS EC2

Tips

SSH into the Linux instance

Produce/consume messages in KAFKA with SAP Netweaver using Java Connector – Part 2/3

Source code

Setup your SAP system

First log in

Install trial license

Developer key

Setting up tools

JDK

To install

To test:

Nano

To install

To test: