Time consumption in ISR forms

[Former Member]

Hi,

I have an ISR form with some 44 fields and it involves some 6 event triggering (to be triggered as per the entry in previous fields in the form). The time consumed for filling such a form is a bit irritating.

I have tried to minimise the no: of events and used the coding standards to minimise the data retrieval as much as posiible.

Still, the time it takes is more, when compared to other user interface applications, on completeing each event. (time taken, also involves, to run the standard codes provided to check the field formating and the kinids)

Can someone give me pointers on how to reduce the time taken to fill a form to the mnimum as posiible.

I apppreciate all valuable/ creative suggestions.

Thanks and Regards,

anto.

[Former Member · Accepted solution]

Hi Anto,

Well it's really a good question challenging the Technology itself.

I think there is nothing we can do on it from Developer point of view anymore(since you had reduced the number of scripts and also followed the coding standards for data retrieval in QISR1 Implementation).

Try using the best scripts so that time for scripts execution will be considerably less.

And also try avoiding the DROP DOWNS from ECC-R/3 which consume lots of time.

Regards,

<i><b>Raja Sekhar</b></i>

[Former Member · Accepted solution]

Thanks Raja for your reply,

Can you please elaborate on better scripts, we have minimised the script usage just to call the events and to change the display pattern. I would like to know which option is better (performance wise)- is it to replace the scripts with aditional fields(to display on various modes) or vice versa. I am following an optimal solution for this.

I would like to have more suggestions.

This is a serious issue for us. The drop downs cannot be avoided, as we cant expect the user to remember specific data to fill all the fields.

Thanks and Regards,

Anto.

[Former Member · Accepted solution]

Hi,

<i>Can you please elaborate on better scripts, we have minimised the script usage just to call the events and to change the display pattern. I would like to know which option is better (performance wise)- is it to replace the scripts with aditional fields(to display on various modes) or vice versa. I am following an optimal solution for this.</i>

<b>See, as the number of scripts increase, the performance will certainly reduce...Scripts are something that gets executed in runtime and obiviously hits the performance. My suggestion to you is avoid scripts as much as possible if you feel the performance is very bad.</b>

<i>This is a serious issue for us. The drop downs cannot be avoided, as we cant expect the user to remember specific data to fill all the fields.</i>

<b>Well,coming to our dropdowns,see the dropdowns work in a way, when we click on any dropdown the corresponding action gets triggered and this action is being captured in backend system and the corresponding code gets executed on this capture. So for every dropdown the whole process repeats. That's the reason I advised you to minimize the dropdown from backend.</b>

Betn us, if the dropdown are quiet simple, why dont you hard code these simple dropdowns(Prefilled dropdowns) to avoid this performance issue.

Regards,

<i><b>Raja Sekhar</b></i>

Message was edited by:

Raja Sekhar

[Former Member · Accepted solution]

Hi,

could you please provide some more details on the events and the scripts you are using (e.g. what are you doing). I assume that you are talking about events of the form?

It's tough to come up with a clear suggestion with only a few pieces of information.

Thanks

Juergen

[Former Member · Accepted solution]

Hi,

The scenario runs some thing like this.

Event 1 :D1 -> D2 (drop down D2 gets populated as per the value selected in drop down D1)

Event 2: D3 ->D4 (drop down D4 gets populated as per the values selected in D3)

Event 3: 2 numeric fields.depending on the values extracted in the previous drop downs(D3 and D4), once the user enters the values in the numeric firelds, the values for other fields has to get calculated and displayed.

The case here is if i use seperate events for D1 and a seperate event for D3. Once triggering D3, the D2 gets deactivated. To make it activated for the second event, i have to populate D2 again.

In effect i have used a single main event name and filterd the data population as per the values in the respective fields.

For each event triggering in the respective fields, it takes a good amount of time.

I just want to know, specifically, any less time consuming way of data display. (And i wont consider hardcoding as the values getting populated is dependent on the value selected from the team viewer)

I hope this is clear.

Thanks in Advance.

[krishanu_biswas · Accepted solution]

Hello Anto,

Thanks for explaining it in details. Though, some of the questions are still unanswered, for example:

1. What are doing with the scripts here ? Are you populating the data in the DDLB on the client ? Isn't the data getting populated on the server into a context.

2. How are you fetching the data from the backend ? Are you hitting the R/3 backend to get the data for every server round trip ?

One more staement i could not really comprehend where you said:

<i>The case here is if i use seperate events for D1 and a seperate event for D3. <b>Once triggering D3, the D2 gets deactivated</b>. To make it activated for the second event, i have to populate D2 again.</i>

How do you loose data as the data must be available in the context ? Maybe, i have not understood the problem correctly which has prompted me raising so many questions.

My suggestion would be to:

- see if possible that you do not hit the backend again and again to get the data and populate it into the DDLB. Maybe, you can do some kind of data caching. Thereby restricting the call till the WebAS only. First call will take relatively more time offcourse.

- If your data is bound to the context then you should be able to avoid any population/repopulation of data during the workflow.

- Write more of a server side code rather than scripts to manipulate data or handle data population.

Apparently, it looks that you need three server roundtrips for the above mentioned scenario and it looks very logical to me:

- D1 > D2

- D3 > D4

- Calculation

I hope, if you had to develop this application in anyother technology other than Interactive Form, you would definitely keep this logic intact. So, technology is not a limitation here. We just need to fine tune our application. But, again, there are exception to everything, always.

Well, i am sorry that i could not pinpoint anything in particular in your application, tuning of which would give you an immediate performance hike. Still, you may take a relook at the above points if they make some sense to your application at all.

Thanking you,

Krish

[Former Member · Accepted solution]

Hi Krish,

Thank you very much for your valuable suggestions.

1. Am using scripts only for data formating and triggering events for each field.

2. The data in the DDL is getting fetched from the backend R/3.

Please give me some pointers in data caching for ISR Adobe forms. The coding is done in theQISR1 BAdi and populating the data structures (special and additional data.). The calculations and data fetching are done as per trhe user entry.

You have rightly pointed what i really need.

I need the areas where i can fine tune this application from a developers point of view. Only point i can figure out is good coding standards.

Kindly Help.

Thanks in Advance.

[Jocelyn_Dart · Accepted solution]

Hi Anto,

Krish's comments are very helpful but of course the ISR technique does limit you in some areas... as with using any existing application framework, you gain something and you lose something.

Because you don't have access the WebDynpro application itself you are limited to what you can do in either the scripts or the QISR1 BADI.

I would suggest you focus first on optimizing the BADI as I can't see an obvious way to cache the data using the scripts.... although someone who is more Adobe Designer savvy might have a suggestion.

For the BADI ... it's true that you return to the backend each time you want to e.g. pick up another drop down. What you need to make sure is that you minimize the number of reads performed by the BADI for each form, i.e. you want to read a particular drop down list once only per form.

There are a number of ways to achieve this but a simple approach may be to check if data exists for the field in the Additional Data tab, and if so do not re-read.

For more complex drop downs you may even need to use some additional hidden characteristics (not shown on the form) to hold last-value-read or similar to minimize re-reads.

Another idea is holding old and new values of fields (via hidden characteristics) so that you only recheck changed fields as this can also reduce the amount of processing required for backend validation via the BADI.

You can also reorganise your validation - e.g. so you only do performance heavy checks when you process an important command such as SAVE.

Also I would agree with Krish that if there is any data that is essentially static - e.g. company code lists which can be retrieved from the backend but in practice very rarely change - where a dynamic read doesn't provide much additional value, either read these once up front when you initialize the form, or hard code them on to the form itself.

And of course look at all your code in the BADI and make sure you optimize the ABAP code - particularly any SELECT statements.

Hope that helps.

Regards,

Jocelyn

[Former Member · Accepted solution]

Hi,

Thanks Jocelyn for your valid points.

am following those as far as possible.

One issue, which i would like to elaborate with regard to time consumption, is -

once a drop down is filled with respect to an event (say D2 from D1)and you select a value in D2.

Now you trigger an another event to populate D4 from D3. After populating D4, if i need to change the value of D2, i am not able to change as the drop down D2 is not activated. What i do is populating D2 again in the second event again.

Am facing this issue in cases when i need to change the form (D2 or D4 values) after reviewing and coming back (CHECK).

I doubt if this is a problem or something i can do from my end.

Thanks and Regards,

Anto.

[Jocelyn_Dart · Accepted solution]

Hi Anto,

Rather than try and second guess what the user may have to change on review, perhaps a more efficient approach (if you really need to protect the dropdown) is to give them some kind of "Reset field x" button, which clears the current selection and repopulates the drop down.

Then at least you would not be re-reading data unnecessarily on the off-chance it needs to be changed.

This assumes you still need to protect the D2 dropdown of course - and can't change the script to leave it open. As the entire Additional Data table is sent to Adobe at once you can of course have multiple dropdowns available at the same time, even though you can only open them up one at a time.

Hope this helps.

Regards,

Jocelyn

[nol_hendrikx · Accepted solution]

Hi Anto,

On which OS does your ADS run? This makes a big difference sometimes Also, how is your performance for default Interactive forms?

Cheers,

Noë

[Former Member · Accepted solution]

Hi Noel,

its on windows 2000 and the performance for forms is okay if they have less no: of fields.

Do reply if you can throw some observations w.r.t these.

Thanks and regards,

Anto.

[nol_hendrikx · Accepted solution]

Windows is not a problem, in most cases performance on Windows (for ADS) is the best.

How long does it take to execute your form in the backend? (transaction SFP).

Let's say the performance is allright in the backend. Now you need to narrow down your problem. Remove some drop down fields and try again. Is there a huge difference in performance, then you know it is one of the removed fields. Put them on your form one by one, till you got the 'trouble' field.

Now you need to check the BADI's (and measure them) where it goes wrong. You might want to use an external breakpoint to debug the ABAP code.

Good luck!

Noë

[Former Member · Accepted solution]

Hi Noel,

The time consumption is for data fetching side, as it has to do a lot of calculation and long list of records are fetched.

From a user's point of view, the time taken is irritating.

The issue i raised is reg to the possible ways of reducing the time. other than the good coding standards.

I can't remove the felds - as they are the requirements.

Thanks and Regards,

Anto.

[nol_hendrikx · Accepted solution]

Hi Anto,

I do understand that you can't remove the field, but for troubleshooting you will need to. Another option might be to temporary hardcode the drop down list and see if this will improve performance.

May I ask how long it takes? Is it a few seconds or do you need to wait for more than 10 seconds?

[Former Member · Accepted solution]

Hi Noel,

if i remove the drop downs, it surely reduces the time.

The case is i have some 4 or five event triggering fields and these are interrelated.

the codes for these have been fine tuned to reduce time.

as it invloves many calculations and data retrieval, it takes considerable amount of time and the time taken for each event is about 1 minute. In essence, it takes about 5 minutes to complete a form and submit (after, all the validations),if there are no validation errors. This will increase if the validation fails.(I have included all the validations at the review stage, so that the validation codes are removed from field specific events. This methodology seems to be acceptable for the users, but not the time taken :(.)

Thanks and Regards,

Anto

[nol_hendrikx · Accepted solution]

Hi Anto,

Wow.... waiting one minute is long

Which fields give the problem?

When you set an external breakpoint (at the beginning of the BADI and the end), where does it take long? Is it before the breakpoint is displayed, after the 1st breakpoint or after the second breakpoint?

Another interesting thing is that when you save your form offline, you can also save the data.xml. If this file is huge, Adobe will render a lot longer (that's not strange).

Tips for more optimizing:

- if you use country codes more than once, just retrieve them only once in your form and reference the other fields to this country field.

- watch out for images, especially bitmaps!

- don't use too many fonts, stick to one or two fonts.

The last 2 optimizing tips won't help you now, but keep it in mind

[Former Member · Accepted solution]

Hi,

I meant the minimum time for a developer is 5 minutes. for a novice user , its atleast 15 minutes after all the validations.

The intersting thing is the time taken is more before and after the customised code. To get to the break point at the start of the BAdi itself take some time and to get back after the break point at the end of the BAdi again takes time.

During these cases (standard code), it checks for the characteristics for the fields and does all validations like date, long text, additional fields and all. basically if the no: of fields and the data (including the additional fields) increase, the time is huge. This happens for a 44 field form, what if i needa lot more no: of fields (This is possible, when most are 'display only' depending upon the input of 3 or 4 fields).

Thanks and Regrds,

Anto.

[nol_hendrikx · Accepted solution]

With other words, the performance loss is not in your code, but before and after it is getting executed (by ADS).

Which version do you run? (NW > ADS)

If you test your form via SFP, does it take long too?

[Former Member · Accepted solution]

NW 2004 and ADS 7.0

ALCD 7.1

Areader 7.0.8

[Former Member · Accepted solution]

Hi Anto,

i think you should check your SP levels, as there are some improvements for ADS as of SP10 for NW2004s (and SP18 for NW2004). I suppose you have the 's' version as you use ALCD7.1

One other option (but with development effort) is to implement the MVC model in the PDF, so only a limit set of the data is generated at a time. I'm unsure whether this is feasable for your form. You could check the adobe site for an example.

Kind regards, Marijn Sponselee

[Former Member · Accepted solution]

Thanks Marijn for your reply, i use 2004 sp18 and installed ALCD seperately.

Will surely do some rnd(MVC model, i doubt if it will be usefull for ISR forms as we are not in Webdynpro) on it.

Thanks and regards,

Anto.

[Former Member · Accepted solution]

Yes,

MVC model is out of ISR scope...

Thanks to Jocelyn for such valuable inputs...in developer's perspective..

Wow,This thread is really informative...

Regards,

<i><b>Raja Sekhar</b></i>

[nol_hendrikx · Accepted solution]

Hi Anto,

Perhaps you can check if there is a patch for SP18. At our project we did not have performance improvements with SP18, but we received a patch for it. Let's call this one SP18+. We are running on AIX, so it might not be available for Windows. Nevertheless, this improved our performance incredible.

Please note that ALCD 7.1 can be tricky if you use NW04. You can separately install Designer 7.0.

Cheers,

Noë

[Former Member · Accepted solution]

The blog <a href="/people/markus.meisl/blog/2006/12/22/a-pdf-form-or-not-a-pdf-form--that-is-the-often-the-question:///people/markus.meisl/blog/2006/12/22/a-pdf-form-or-not-a-pdf-form--that-is-the-often-the-question sums up the issue in short. Thanks Markus

Noel,

Can you please elaborate on issues with ALCD7.1 in NW 2004. Am just curious to know about it.

Thanks and regards,

Anto

[nol_hendrikx · Accepted solution]

It is quite unknown what will go wrong, but in our system fields with a corner around it is being displayed properly when saved with Designer 7.0. In Designer 7.1 the top line is missing.