cancel
Showing results for 
Search instead for 
Did you mean: 

Execution time issues with SU01 demo script

0 Kudos

Having worked with Scripting in a Box for a while now I wanted to try out the examples there. I read explaining why my attempt to narrow the returned users failed (Craig, did you find out why the functionality was removed?) and seeing that Harry had the same problems with only ~200 users in his system. However, Craig's original post states he successfully managed with over 400 users. I'm a bit confused...

I included some simple timing stuff and found out that processing of one user in the loop takes about 1.7 seconds - little surprise then that every script times out. This seems to be due to the additional calls to GetStatus() and GetValid() - by commenting them out I get the whole list rather quickly.

Unfortunately commenting them out also means no nice icons for 'Status' and 'Valid', which is not desired. I probably could create a Z FM to deliver me the userlist with these two fields already added (which would save on rfc-calls, assuming the operation is much quicker on the server directly), but I hoped to get a solution based purely on PHP, not own ABAP coding (being aware that Craig also used a Z FM anyway, but still...)

I'm a bit unsure now how easy it is to actually create useful frontends in PHP, with such long execution times. I assume this will happen in other occasions as well, not only for user lists. Is there an alternative? Or a general way to do those things quicker?

:Frederic:

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Why functions are removed is often one that requires racking down 20 developers and asking if they remember why they were told.

Now the script was designed for a small test system in mind and if you have the basis skills you can make it run with about 0.0082 per user record (including the second and third function calls) however that means making some system index modifications, etc.

A single call can be done but requires a custom function the other option is to cache the values and then display - I honestly did not put a lot of time into the demo because it was simply a demo.

One suggestion which I implemented just to play more with AJAX type stuff was to call - get the list then onMouseOver of each record do the calls for the additional info - again though it's a matter of taste and what you want - be a cool coding challenge.

<b>Any takers say a physical on site coding day in Walldorf in the new year?</b>

Former Member
0 Kudos

Two more possibilities........

1) In this case (where we talking about large number of records), I feel paging would be appropriate.

2) Could the AJAX synchronous callback work for RFC's? Trigger the RFC and route the completion of execution of RFC to a handler. This way we would have archived responsive UI and paging together.

0 Kudos

Craig: you say it's easy to go from 1.7 seconds per user lookup down to a small fraction of it? Then apparently I'm lacking these skills. Could you please give me a hint what should be done there?

I though about creating a Z function, but having to write custom wrappers - possibly for about any transaction in this style - I wanted to avoid.

Bala: the two functions only take one user as input, not a list. So w/o modifying the ABAP side I can't feed the whole list in there. I wonder how much it would improve the result time anyway, so perhaps I'm trying it. It's just not a solution I'd prefer.

Paging is a good idea, the actual call to get the whole userlist is quite quick. Having like 20 users displayed at a time is manageable - still slow, but the script won't timeout anymore. I think I'll implement this today.

About AJAX: yes, I want to play around a bit with AJAX, however having the two columns valid and status removed and the information only displayed on mouseover etc is a bit like cheating. And 1.7+ seconds waiting for a hoover info is too long. So I'd like to optimize on the rfc-calling side primarily.

Craig: surely it was just a demo, and I'm just trying to get it to work for understanding it

:Frederic:

Former Member
0 Kudos

2) you have the problem that several standard functions don't give you the fine detail of choosing which record to start with meaning you need to call it all once and handle it completely outside of the RFC

Former Member
0 Kudos

I created another demo (should be here on SDN somewhere) using AJAX for the call so it was not hard at all just a matter of what library you choose.

As for the optimizing side you need full (sap_all) rights to the server or a custom profile for modifying indexes for the table then you set a trace on your call and see where you can begin optimizing on the system side (it's not a straight forward - go click here) so it's a process style one.

We should do the coding day and invite others and cover all that stuff together it's quite extensive stuff.

0 Kudos

Ah, I see - you're speaking about profiling and optimizing the server side, like the ABAP code or table indexes. While perhaps worthwhile to look into it, I think it's a bit out of scope when doing a scripting project. I'd assume - as PHP developer - that I can just use what the system provides and don't have to modify the SAP backend.

Or am I wrong, is the provided functionality too complex and partly too limited to accomplish this w/o tampering with the system? I noticed you needed your own small wrapper, too.

:Frederic:

former_member583013
Active Contributor
0 Kudos

Even when the FM's are RFC Enabled....Sometimes you need to modified them in order to achieve some goals -;)

In my blogs....I have created almost 10 Custom FM's....It's would be nice to make modifications only in PHP....But in my experience....You need to make some ABAP tricks.....

Greetings,

Blag.

0 Kudos

That's a pitty, I hoped it would be easier. But you seem to have done quite a lot, so I just believe you here.

I assume we have to create quite some helper functions for your php framework then, too?

:Frederic:

Former Member
0 Kudos

Vanilla SAP does an awesome job but with any large DB related system you have to fine tune and optimize and try as we can SAP can't think of every little scenario someone might want therefore custom programming does come into play however for many things and I mean many this is not the case "out of the box" works great.

Former Member
0 Kudos

Hello Frederic,

Instead of looping through all users and invoking the BAPI n number of times, cannot you use a single call to get all the user related data in a single call, like using the user group or user profile? This would atleast save n number of RFC calls to the backend.

Regards,

Bala.