SFP saving of forms performance issue

[Former Member]

Hi all,

I have a ABAP stack installation where Adobe forms are being developed. When a new form is created with few objects (text fields etc) are place in the form, the save button can manage sub-30sec save times. However, when additional text fields are placed into the form, the amount of time required to save quickly increases to 10-20mins or more.

I see has similar issues, but I can't see which parameter change in FPCONNECT would help.

I would appreciate if someone can provide abit more information on how to reduce (drastically) the save time. This amount of save time on a form with a dozen text fields is unacceptable.

Thank you.

[Former Member · Accepted solution]

Hi,

As a part of ADS post installation configuration, we have an option of defining caching at both client and server level.

Server side: If you open table FCONNECT in SE16 Tcode, you will find a field named cache or such, just say X to this value.

Client side: in sfp tcode go to form properties, in one of the tab you will have an check box to specify client cache just check this box.

Besides there was a bug in ADLC in version 8.2.2 here if you copy and paste UI controls on the form, it automatically keeps on adding some tags repitatively. with this a form of 10kb might grow upto 50 MB in no matter of time.

To remove this you need to identify and delete these entries from the XML Source tab, and from there onwards upgrade tour ADLC to 8.2.3 or ES2.

Let me know if this solves your issue.

Cheers,

Sai

[Former Member · Accepted solution]

Thanks for the reply Sai; but our developer feedback on the suggested actions are that they do not produce appreciable results to the performance of the form saving. Any other suggestions?

[Former Member · Accepted solution]

Mate,

may be, but somehow doing so, my form which is of 3 MB taking 10 minutes to save or activate, is now hapenning in 1.5 minutes.

Cheers,

Sai

[Former Member · Accepted solution]

Hi Sai,

Updated that your initial answer solved the problem. Apparently the developer was not aware Livecycle was a frontend installation. Once that was done, we had managed to verify that the size of the generated form was drastically reduced. He comments that it is ok now.

Thank you very much!

[Former Member · Accepted solution]

Cheers Mate...!

Good to hear that your issue is solved.