Status of server support

[samuel-c-allan]

This issue is mostly a question but also a comment on documentation.

The team I work with desperately needs server support in our application (which is currently heavy on use of node-rfc) but I am currently finding it very hard to tell if (and to what extent) ABAP-to-JS calling is supported as the README is very unclear about this.

Inspection of Server.cc and some tests with the example experimental code have led me to believe that the basic connectivity is supported but the JS callback has not yet been implemented (in fact there is some commented out code in Server.cc that seems to be intended to support this).

Due to the urgency of our requirement I will certainly be implementing the missing functions in C++, but if the opportunity allows I would greatly wish to contribute to work on the server functionality or in the case that it is already implemented and I am misusing it, to understand what is going wrong. Except the following prevents this (and this is the main complaint of my issue): It is very much unclear from the README where the current work on the server stands, what is supported and what is up for contribution (there is a months old server branch which also raises more questions than it answers.

Looking forward to any clarification on the matter and again, I would certainly be willing to contribute to this.

[bsrdjan]

Hello @samuel-c-allan,

the sever functionality is not yet available and please ignore the old server branch, is just a leftover to be removed.

The commented code Server.cc#173 are three main steps of processing ABAP to Node RFC call:

1. ABAP RFC input data conversion to JS data
2. JS server function call (with JS data)
3. JS server function results conversion to ABAP RFC output data

The cycle is basically "inverted" client request cycle, in which steps 1) and 3) are exchanged. In client case JS data are converted to ABAP RFC input and ABAP RFC results is converted back to JS. These conversions were implemented for Client scenario and after (bigger) re-factoring re-used for Server data conversions.

The step 2), one-liner JS function call at line 183, is also implemented, leading to legitimate question, with all functions in place what is actually missing?

ABAP RFC call comes from external system, registered by node-rfc server and the handler section with commented code is invoked. ABAP system is external independent system from NodeJS perspective and ABAP RFC call is registered in a separate thread. All works fine, as long the handler does not touch JS data. With these handler steps un-commented the exception is raised because any JS access data must be synchronised with v8 event loop.

The contribution could help with adding the synchronisation, following:

• node-addon-api/#779 and
• node-addon-examples/thread_safe_function_round_trip/napi/round_trip.c

I would be glad to help with more info, exchange or test env configuration.

[gregorwolf]

Dear @samuel-c-allan,

why would you need to use RFC for calling a JS functionality instead of using the ABAP HTTP Client to call a HTTP Endpoint implemented with NodeJS?

Best regards
Gregor

[samuel-c-allan]

@gregorwolf This would be a good solution but unfortunately we have to work with very old systems which do not support the http client (namely 4.6c), plus I am happy for an opportunity to contribute to a project I use so extensively :)

[samuel-c-allan]

@bsrdjan Thank you for the awesomely detailed descriptions, I will thoroughly inspect all the code and the thread safe call example and get back with any questions / suggestions / whatever I find. I am very excited to be able to work on this part of node-rfc and further my understanding of V8 in the process.

[gregorwolf]

Just out of curiosity: The extended support for SAP R/3 4.6C ended 31.03.2013. So how is that system supported to run in a productive environment?

[samuel-c-allan]

Very valid question. Our product is intended to extract information from these older systems in order to help take them offline and you would be surprised how many people actually use these systems for better or for worse.I am sorry if I can't really explain it properly, I am just uncertain to what extent I am permitted to reveal the functionality at this stage (obviously later on the entire framework will be known).

[gregorwolf]

Interresting. But woudn't an extraction on DB level be easier to acomplish?

[samuel-c-allan]

Depends on what you mean with a db level extraction. If you mean a non-ABAP mediated extraction, this would possibly work but many of our clients have refused this approach for all sorts of internal reasons like preventing access to sensitive data, etc so at the end of the day that's the real reason (many clients will refuse running even harmless native sql). I myself am frustrated at many of the restrictions imposed that complicate the approach but I think the server method will be the cleanest way of achieving all this and in the worst case it isn't a horrible way of doing it and will certainly work, it is the cleanest of the dirty ways of achieving the result as far as I can see.

[gregorwolf]

But in regards to access to sensitive data there is no difference between native SQL and Open SQL in ABAP. Nothing restricts a developer.

[samuel-c-allan]

Absolutely. Now try and convince our clients and I will immediately switch to the much more sensible approches :P As I said, frustrating for someone with knowledge and understanding since I am aware of how much simpler and faster things could potentially be

[samuel-c-allan]

Alright so I read up on all the materials and have this basic plan of action in mind (step by step):

• Create a proof-of-concept version of round_trip (the same prime generating program) that has a synchronous system closer to what is expected here using libuv condition variables. This may be awkward for the primes program but will ensure we are on the same page given my limited experience with libuv
• Carry over the concepts from round_trip over to the server logic here, replacing ThreadItem with a version better suited to storing the request/response information
• Implement the wait for some condition variable after calling the JS function and a notify after the JS function resolves/returns (is a promise-based system better here? Or just notify whenever the function returns?)

This seems to be the basic idea, as you can probably tell I haven't worked with all of these technologies extensively in the past but if this plan sounds good I will go ahead with step 1 (adapting round_trip).

[bsrdjan]

It looks good to me. The simulation in step 3 could be eventually avoided and replaced by local RFC server test, using node-rfc client to call node-rfc server. From node-rfc server perspective there is no difference, it anyway does not "see" if ABAP or node client is on another side of RFC connection. The setup was not possible at the time when I was working on this but with WebSockets RFC support added in NWRFC SDK PL6 the local test should be possible. Will check that.

Reading about the extraction scenario, would it be easier to use the RFC client to pull the data from ABAP system? Extraction using node-rfc server looks like more efforts to me because of (custom?) ABAP reports required to to extract and push the data to node? But if already existing reports can be consumed then it is of course easier.