RFC once with partially redundant coding or several times without redundancies?

[Lukas_Weigelt]

Hey folks,

Background

I'm currently designing a Custom Task Provider for the Fiori My Inbox 2.0 with means of the Task Gateway via oData. By now, I've concluded what Business Logic I need for data retrieval, which will have to be done via RFC, since the data lies on another system, i.e. I'm implementing a Facade-Class as Data Provider on the Gateway, but the data which is supposed to be managed, resides on our ERP System.

Luckily, all the logic I require for initial data retrieval is provided by 4 Standard Function Modules on the ERP System, so far so good.

Question/Discussion

At the moment I'm trying to figure out what would be "best" or rather what would be the best compromise of an approach. I got two ideas so far and would like to bring them up for discussion:

A) I incorporate the 4 Remote Function Modules in the respective methods of my facade class which means they will be called individually in a nested callstack. There will be no coding-redundancies, neither inside the facade class nor between the two SAP Systems (Gateway and ERP) but there will be 4 to X (assuming X = up to several hundred in the worst possible case) single RFCs.

B) I build a Wrapper-Class inside the ERP-System, do all the data retrieval locally, theoretically have the possibility to reduce the retrieved data to the actual parts that are needed on the Gateway and make exactly one RFC from the Gateway to the ERP-System retrieving the entire bulk of information "logically" once, technically, though, it might happen several times inside the Task Gateway Framework/Model, i.e. it might happen that the entire bulk of information is not called once but, say, a couple of times which is functionally nonsense, but the framework might call certain methods several times and I might not be able to hold all the information consistently (I don't know this yet; might be there will really only be one RFC and that's it). This would mean I'd partially have redundant business logic on both, the Gateway and the ERP System AND potentially a bigger data load (at least content-wise) via RFC overall.

Presently I'm torn which way to go with. The coding redundancy with approach B) is something which I personally detest, though, it would not be so bad that it would make things confusing or difficult to maintain; it's more a matter of principle. On the other hand, performance might go down a wee bit with approach A), but most likely not humanly noticeable, assuming the endusers will clean up their workspace from time to time, <conspiracy-theory>which they most likely won't</conspiracy-theory>.

I'm also open for completely different approaches, assuming that I've gone a little numb from hours of debugging and/or being routine-blinded.

Cheers, Lukas

[Lukas_Weigelt · Accepted solution]

cleaning up old threads. /closed

[weberpat]

+1 for approach B

I have not worked on this specific scenario before but we've had several occasions in the past where projects started out orchestrating multiple RFC calls to the backend from a middleware platform and then had to turn to a wrapper function for performance reasons. We never had the opposite situation.

[Florian]

I would go for option A.

Short version is the transperency. Whenever you want to limit one or more options, no matter what you expect to have in future here. And as you already mentioned, I don't think there will be a big delay while having 4 or more rfc-calls at the end. So having in mind I do not have to double a lot of coding, which will make this approach ugly I like approach A.

B is just not my joice, because of the redunant code on 2 systems. I know from my own experience that someday there will be a problem and it takes time to figure out which system to go 🙂

~Florian

You know, everything returns a day...got yesterday my very first functionmodule on the screen to check the HANA readiness... never expected that

[former_member182550]

Off the top of my head I would go for a cached data approach on the mobile side if possible to reduce network load and increase response time. However, I agree with Simone - approach B

[SimoneMilesi]

Uhm, ok... it's one year i'm playing with oData and GW but i'm working on NW731 and my GW and the ERP works together, without any third party coming in so i'm probably the last person you need to listen about your problem 🙂

My 2 cents on the topic: if the 4 FMs are called (like it seems) all together, better to create a wrapper.

In this case you make just 1 call from GW to ERP and got 1 response instead of keeping to dialog between the 2 systems.

From what i understand reading your other questions and their links, GW is only sort of proxy receiving a request (From Fiori layer) and passing it to the corresponding Backend.

Let the Backend (a.k.a. the ERP system) to do its work: handling data, chewing them and then spitting the result out.

So, if i've to choose an approach, i'd go with option B.

But, again, it's probable i'm wrong 🙂

[SimoneMilesi]

Hi Lukas,

i do not get the issue, so i'll ask you a couple of things to clear my mind: hope you'd not mind!

The 4 FMs are need to retrieve the whole set of information or they refer to 4 different entities (i.e. via Deep Entity)?

i found that working with Deep entities can be useful if your set of information are retrieved in different ways yet are all linked and grouped.

[Lukas_Weigelt]

@Florian, long time no "see" ;-), thanks for your opinion. With all the input I have now, though, I tend to building a wrapper on the ERP system and call that one, hoping that the TGW-Framework will be nice to me and maybe I can "cache" the data in a consistent way. That way I'd have the benefit of both approaches and the disadvatanges of neither.

Don't get me wrong, though, I know exactly what you mean. I'm still maintaining my first "bigger" implementation from the time I had no idea what I was doing nowadays -_-

[Lukas_Weigelt]

Thanks @Richard and Patrick for your input, seems option B is about to win the race.

[Colleen]

I posted on Twitter and Florian said option A but he needed time to write a reply. Just an fyi

[Lukas_Weigelt]

Oh my goat, does that mean you are my personal push-notification-proxy from SCN to Twitter now? 😉

Jesting aside, thanks a lot for doing that! 🙂

[Colleen]

Well thought out intelligent questions deserves attention and response

[Lukas_Weigelt]

There's hope for this network afterall ❤️

[Lukas_Weigelt]

I converted your comment to an answer. so I can "accept" it lateron (for sake of forum tidiness, for what it's worth >.<), I hope you don't mind.

It's more like the other way around. The UI (Fiori App) and the Task Gateway Service are both on the Gateway System (FES/Central Hub) and the Facade Class on the Gateway acts as a proxy between Task Gateway and Data from a Backend (in my case ERP). But still, the initial "problem" remains the same, i.e. your argumentation is legit to keep the ping-pong between systems to a minimum.

I don't think there's a "right or wrong" here, at that, your opinion on the matter is very much appreciated! 🙂

Any more opinions on the matter (wake up, Matt!) are highly appreciated!

[SimoneMilesi]

i agree: not right or wrong, just different approach. 🙂

[Lukas_Weigelt]

Hi Simone,

thanks for your reply! I don't mind at all, on the contrary! 🙂

In before: I forgot to clarify my hard skills: I'm more or less playing around, trying to achieve a requirement with means of customizing and sole ABAP Programming. I have no experience concerning development with oData and UI5 whatsoever, meaning I might overlook certain approaches simply because lack the farsightedness. With my current knowledge I assume (can very well be wrong) that I have to do some kind of RFC call, either directly or with means of a Backend Operation Proxy (see my other thread --> https://answers.sap.com/questions/278942/index.html)

The 4 FMs are needed or rather have to be called in sequence (they complement each others) to retrieve the whole sets of information. I'll try to elaborate with a picture:

If this is somehow possible solely with means of oData, I'm all ears (even if I probably won't understand it initially and will have to do some research).

Cheers, Lukas