JCO vs aRFC

[Former Member]

Hi all,

I want to implement communication between my web dynpro and an R3 backend system. I've done this before, but i'm wondering about the technique to use.

In the article "Effective Web Dynpro - Adaptive RFC Models" I found the following and i quote:

"<i>SAP strongly recommends using the Adaptive RFC Adapter instead of implementing another technique for accessing RFCs based on the JCo communication layer.</i>"

Is it really better to use aRFC instead of using plain JCO code directly? (JCO.Function..getImportParameterList(), ... )

I think it is much more cleaner when using the plain JCO way instead of the aRFC way. With aRFC, even for a simple BAPI you receive lots of generated classes and i think it just looks messy.

Am i wrong when i think that plain JCO has also better performance than aRFC?

Kind regards,

J.

[Former Member · Accepted solution]

Hi,

Technically speaking you may be right.

But the use of adaptive RFC's enforces the developer to stick to the MVC principles (and fetch your data from the model).

I have seen a project where data was fetched (through JCO) in the view components. This is very undesirable.

So sticking to the RFC import has architectural advantages. However, if you know what you are doing (e.g. create custom controllers for importing backend data), proceed in whatever way you want.

Good luck,

Roelof

[Former Member · Accepted solution]

Thx for your reply.

So if i put the backend communication ( execution of the rfc functon to retrieve data) in a separate custom controller, it is still good design?

I am going to call a Web Service too, so i need a model anyway, but I hope the model for a Web Service is cleaner

Kind regards,

J.

[Former Member · Accepted solution]

Joren,

Here I've briefly summarized differences or cons/pros of Adaptive RFC Model (A-RFC), SAP Enterprise Connector (SAP EC) and plain JCo:

Also there is yet another way to access R/3 back-end: SAP JCA adapter. I would avoid mentioning WS access -- it adds serious overhead without any significant benefits.

As of MVC principles, you may create "MVC-compliant" application with either A-A-RFC, SAP-EC or JCo. The reverse is also true Just make sure you use right tool for the right job:

1. Generic library for R/3 access with intensive low-level coding and fine-grained control: JCo

2. Application specific model that must be called from either EJB or stand-alone Java -- SAP EC

3. WebDynpro -- A-RFC with its built-in configurable via SLD connection management and DDIC access.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[Former Member · Accepted solution]

Hi Valery,

So as long as i dont mind doing the low level JCO programming in which i specify the names for the parameters and structures and so on... there's nothing wrong with using JCO from Web Dynpro too. Maybe EC is a good way for going for the in between (between plain JCO and ugly model aRFC) aproach...

The WS approach is needed because we need to call R3 from existing J2EE application and we dont need to write new code for calling a WS... I think that is the only advantage of a WS, you can call it from everywhere like just any other Web Service...

Suppose i would still implement it with aRFC, what is the best way to do context binding here? Directly from view context to component context to model context? so the model context will be filled automatically...

Or is it better to do the fillin of the model context manually via an intermediate node in the component context?

Kind regards,

Joren

Kind regards.

J.

Message was edited by:

Joren Crauwels

[Former Member · Accepted solution]

Joren,

<i>So as long as i dont mind doing the low level JCO programming in which i specify the names for the parameters and structures and so on... there's nothing wrong with using JCO from Web Dynpro too. Maybe EC is a good way for going for the in between (between plain JCO and ugly model aRFC) aproach...</i>

It depends what to call "ugly"

For me JCo is not the best API, it's hardly an OOP but rather C-style like. Though, not surprising, because it's in fact same libs for Java and C and you may use JCo from native applications developed in C or other languages.

<i>The WS approach is needed because we need to call R3 from existing J2EE application and we dont need to write new code for calling a WS... I think that is the only advantage of a WS, you can call it from everywhere like just any other Web Service...</i>

I'd rather try SAP-EC (it generates typed wrappers). Or JCA if you talk about J2EE applications (like EJB or WAR projects). Anyway, it's up to you -- the only thing to note is that A-RFC available only to WD applications.

<i>Suppose i would still implement it with aRFC, what is the best way to do context binding here? Directly from view context to component context to model context? so the model context will be filled automatically...

Or is it better to do the fillin of the model context manually via an intermediate node in the component context?</i>

Typically you create model nodes based on A-RFC in component controller, then uses these nodes from view controller via context mapping. Just to separate view and controller parts. By the way, try to right-click on your component (or component controller, I do not remeber exactly) and apply "Service" template. You'll be surprised how many code is autogenerated on your behalf

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[Former Member · Accepted solution]

Hi Valery,

I am trying all options now. I hava a problem with the plain JCO option.

When i do the following:

JCO.addClientPool(poolName, nrOfConnections, client, user, pw, lang, host, sysNr);

I receive the following exception:

com.sap.mw.jco.JCO$Exception: (101) RFC_ERROR_PROGRAM: 'password' missing

The same code is working in a local Java projct. Am i missing something here? Does there have to be some configuration before it works in my locally deployed web dynpro application? Is it possible that in SLD (not local) it is defined to use SSO with the R3 i am connectin to and that i have to call another method to connect?

Kind regards,

J.

Message was edited by:

Joren Crauwels

Message was edited by:

Joren Crauwels

[Former Member · Accepted solution]

Joren,

First, SLD is not involved here at all.

Second, your code looks correct, the only problem possible is <i>pw</i> equals to null or empty string.

VS

[Former Member · Accepted solution]

Hi,

The communication with R3 via aRFC and plain JCO (both from Web Dynpro) is working now. It seems that the time to execute the function is alot faster using aRFC than when using JCO. Is this possible, or does it mean that i'm doing something unefficient somewhre? I calculate the time like this:

StopWatch sw = new StopWatch();

sw.start();

function.execute();

sw.stop();

long time = sw.getTime();

Kind regards.

J.

[Former Member · Accepted solution]

Joren,

This is impossible while aRFC uses JCo underneath and it should just add small overhead

Your expiriment are not correct, try the following:

final int N_RUNS = 100;
StopWatch sw = new StopWatch();
sw.start();
for (int i = 0; i < N_RUNS; i++) {
  function.execute();  
}
sw.stop();
long time = sw.getTime() / N_RUNS;

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[Former Member · Accepted solution]

Hi,

I know that aRFC uses JCO under the hood, that's why i was surprised. Is it possible that aRFC for the moment is faster than my plain JCO way because with aRFC all the parameters that are not retrieved to the controller context are put to inactive (under the hood)? I am not doing this in my plain JCO code, so it receives everything back, not only the parameters i need.

Kind regards,

J.

[Former Member · Accepted solution]

Joren,

Probably you are right -- inactive parameters may save a lot of time especially for tables / structures.

VS

[Former Member · Accepted solution]

I think the reason my jco is slow than i'm doing something inefficient with my connections.

Is it possible though that aRFC is really optimized for Web Dynpro, meaning that its hard to write JCO code that's faster?

Regards,

J.

[Former Member · Accepted solution]

Joren,

I see only 4 ways to optimize performance of JCO (and A-RFC uses all of them):

1. Use connection pooling. Are you sure you are calling addPool only once and then reuse connections from pool?

2. &#1057;ache metadata (defitions of RFC functions, structures, tables) in JCO.Repository.

3. Deactivate non-used parameters

4. Laizy load data from JCO.Record to application-specific structures. In A-RFC collections of ICMIGenericModelClass-es are laizy loaded from JCO.Records.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net