1

Compared with building a complete set of information systems from scratch, secondary development based on mature ERP and other industry software is the preferred solution for more medium and large enterprises to meet their personalized software needs. How to reliably read and write the database of the finished software in the second-open module to meet the system integration requirements such as automatic document creation and automatic metadata synchronization is a difficult problem for developers. Today, we take SAP HANA as an example in the technical support work based on the movable type low-code platform, and introduce several typical routes for you.

Option 1: Directly connect to HANA through ODBC to operate raw data

The client program of SAP HANA provides an ODBC data source, which enables the development team to directly connect to the HANA database through ODBC, and to read and write the original data in the database through SQL statements.

(Operate HANA through ODBC)

First, we need to configure the ODBC data source provided by SAP on the servers in the development environment, test environment and production environment. After installing the SAP Client (x64 is recommended), open the odbc data source management program of the system (note the distinction between 64-bit and 32-bit, which needs to be consistent with the SAP Client). Click "Add" in the "System DSN" tab, select HDBODBC, and then follow the interface prompts to enter the name of the data source, such as "HANA-Test Library", server IP address, user name and password.

(Creating an ODBC data source to HANA)

After the configuration is complete, we can read and write SAP HANA data just like other databases. Back in the movable type, we use the "connect to external table" function to introduce all the data tables that need to be manipulated in HANA. After that, you can use drag and drop to complete data binding, or splicing and executing SQL statements on the server side.

(Introduce ODBC data source in movable type low code platform)

If you just read metadata or some simple documents, this solution is indeed a simple solution. However, SAP's data table structure is complex and lacks effective database script tracking capabilities. It is difficult for us to determine which fields of which tables need to be manipulated in a document creation process. Therefore, when it comes to a slightly more complex application scenario, the risk of directly manipulating raw data through ODBC is higher.

(Pure code, operating HANA data table through ODBC)

Based on years of technical support experience, we generally do not recommend this option to our customers.

Option 2: Call NetWeaver API to operate business objects

SAP is also clearly aware of the reliability risks brought about by developers directly connecting to HANA and manipulating raw data. Therefore, SAP launched the NetWeaver integration platform to provide developers with an original factory-level two-open solution, "trying to" ensure that the written data will not pose a threat to the operation of the SAP system. However, the development cost of this platform is still unsatisfactory, so that most developers gave up this solution at the beginning of the second-opening project. However, the operation of the original data in the data table in NetWeaver is encapsulated into the operation of the business object, and some necessary verification logic is added, which is very meaningful for Erkai. More importantly, these encapsulated interfaces are open. Even if we adopt other two-open solutions, we can still call the HANA operation capabilities provided by NetWeaver through the RFC protocol, so as to avoid the risk of directly reading and writing raw data.

After the introduction of NetWeaver, the two-open module can no longer directly operate the HANA database, but through the RFC bridge located on the two-open server (if the maintainability requirements are not high, it can also be directly integrated into the two-open module) and located in the SAP cluster. in NetWeaver to complete. The two-open module calls the RFC bridge through HTTP and other protocols, and the RFC bridge transfers NetWeaver through the RFC protocol, and NetWeaver is responsible for directly corresponding SQL statements on HANA.

The reason why we abstract the RFC call part into a special RFC bridge module is mainly considering that this part adopts a third-party component library (SAP's original .NET SDK has a bad reputation), and isolates it from the two-open module , which can effectively reduce the maintenance risk. Because the customer adopts a low-code development method, the implementation method of this RFC bridge is a custom WebAPI developed based on the movable type server-side programming interface. For pure code developers, the RFC bridge is usually an ASP.NET MVC or Java SpringBoot web service. In terms of implementation logic and architectural principles, low code is similar to pure code, and both need to be completed by writing code.

(Operating HANA via RFC + NetWeaver)

Step 1: Use C# to develop an RFC bridge that calls NetWeaver

In this step, we need to use Visual Studio (screenshot is VS2021), movable type server programming interface (screenshot is movable type V7.0 Update1), SAP NetWeaver RFC SDK (screenshot is 7.5) and open source project SapNwRfc ( https ://github.com/huysentruitw/SapNwRfc ). Among them, the SAP SDK requires the customer to use the SAP account and download it from the SAP official website.

First, we create a .NET 4.7.2 class library project in VS2021, and reference sapnwrfc.dll in the lib folder of the RFC SDK; then find and install the SapNwRfc package and the Microsoft.AspNetCore.Http.Abstractions package (movable type service) through nuget The terminal programming interface needs to depend on this package); finally reference GrapeCity.Forguncy.ServerApi.dll in the installation directory of the movable type server program. In order to ensure the normal operation of the RFC SDK and simplify the deployment operation, we recommend that you copy the RFC SDK files directly to a directory under the system disk, and add the lib folder under this directory to the system PATH variable to ensure the operation When the referenced sapnwrfc.dll can be found exactly.

(SapNwRfc package in Nuget)

Then, we need to create the classes corresponding to the incoming and outgoing parameters of the RFC according to the SAP documentation. SAP prepares an Excel file for each NetWeaver interface, which records the method name, the type and structure of incoming parameters and outgoing parameters. We only need to find the Excel file corresponding to the interface to be called, and create the class corresponding to the input and output parameters according to the requirements of the document. It should be noted that the name of the attribute and the value of the SapName tag must be strictly consistent with the parameter name in the document. Taking creating a vendor as an example, we need to create an incoming parameter class: CreateVendorParameters and an outgoing parameter class: createVendorParametersObj.

(The parameter structure corresponding to the interface for creating a supplier in NetWeaver)

Then, we create a WebAPI in the project, a class GetSAPInfo that inherits from ForguncyApi, and then create the response method CallRFCFunction for the POST request (the method name and the class name form the Path part of the URL). In the code, we read the connection string, methods and parameters to be used from the request, call the corresponding method of the SapConnection class for processing, and finally serialize the result and return it to the caller of the WebAPI. Like the property name, the method name passed in when calling SapConnection needs to be strictly consistent with the text in the document. For example, the method name for creating a supplier is ZLIFNR\_CREATE.

(WebAPI implementation of RFC bridge)

According to past experience, in order to lower the learning threshold for developers who call the RFC bridge, so that they can also directly operate with reference to the documents provided by SAP, we recommend integrating all the interfaces used into a WebAPI, and passing the SAP method in the code name to switch branch.

To use these sample codes, you can get them from Code Cloud: https://gitee.com/GrapeCity/lowcode\_extention\_demo\_hana\_via\_sap\_rfc

Step 2: Invoke the RFC bridge in the movable type

The WebAPI developed by using the movable type server programming interface is exactly the same as the WebAPI developed by pure code. When using movable type to develop a business system, it can be called by the "send HTTP request" command.

First of all, in the development and testing environment, we usually connect to different SAP databases, so we need to store the necessary information required to connect to NetWeaver in the database and publish it with the program, rather than writing it in the code or global configuration file. middle.

(NetWeaver connection information stored in database)

When we need to operate SAP data, we need to use the "set variable command" to read the parameters of the HANA database used in the current environment from the database, and concatenate them into a connection string; then use "send HTTP request command" to call WebAPI for RFC Bridge.

According to the implementation of the RFC bridge in step 1, its URL address is customapi/{class name}/{method name}. We also need to set the connection string and method name in HEAD (from the Excel document provided by SAP, such as ZLIFNR\_CREATE).

(Configure NetWeaver's connection string and method name)

The specific request parameters need to be set in BODY, and the business data of the second-opening system is passed as parameters to HANA, and the corresponding data operations are performed to finally achieve the effect of system integration.

(Configure the business data passed to NetWeaver)

The following is a demo of the quick-build movable type integrated with SAP NetWeaver when we help customers with technical evaluation. To use this project, you can get it from Code Cloud: https://gitee.com/GrapeCity/lowcode\_demo\_hana\_via\_sap\_rfc

(The effect of integrating SAP HANA with movable type)

Discuss

In order to help developers do secondary development, most mainstream manufacturers such as SAP and UFIDA provide two development modes: direct database connection and encapsulated business interface. In the pure code development mode, the biggest difference between the two modes is that the former has a higher performance limit and the latter is more reliable.

After entering the low-code era, the mode of encapsulating business interfaces has shown a stronger competitive advantage. For example, in today's example, with the help of the RFC bridge, developers of business applications can easily read and write operations to the HANA database through visual configuration, all without having to master any programming language. Professional programmers use the platform's programming interface to expand platform capabilities, and non-professional programmers use these capabilities to visually complete system development. This "mixed mode" is becoming the mainstream of low-code development.


葡萄城技术团队
2.7k 声望28.6k 粉丝

葡萄城创建于1980年,是专业的软件开发技术和低代码平台提供商。以“赋能开发者”为使命,葡萄城致力于通过各类软件开发工具和服务,创新开发模式,提升开发效率,推动软件产业发展,为“数字中国”建设提速。