OnDemand User Group

Support Forums => OD/WEK & JAVA API => Topic started by: pankaj.puranik on July 24, 2013, 11:14:25 AM

Title: Pagination
Post by: pankaj.puranik on July 24, 2013, 11:14:25 AM

Hi

We have a big AFP file that is loaded into CMOD.
Each account has 2000 plus pages.

During retrieval this AFP is tranformed into a PDF using the afp2pdf transform.
Understandably, it takes long (40 seconds) to render this PDF due to it's size.

I wanted to know if there is a way to solve this problem.
Can CMOD stream only first few pages of the PDF as and when the user scrolls further?

Thanks
Pankaj.

Title: Re: Pagination
Post by: Alessandro Perucchi on July 26, 2013, 08:23:36 AM

Hello Pankaj,

stupid question :-) but why do you need to transform such big lists in PDF? Would it be no better to have them looked in AFP?
Otherwise, it would be to store the documents directly in PDF... it would be better for the retrieve time.

Using ODWEK to do that, I suppose you need to know the AFP format in order to know where begin a new page and finish a page.
Then you could simply cut the pages, and deliver part after part of PDFs... or something like that.
That's only an idea.

Sincerely yours,
Alessandro

Title: Re: Pagination
Post by: pankaj.puranik on July 26, 2013, 01:07:30 PM

Alessandro

The end users will possibly not have AFP viewers and the current code doesnot use the applets.
So these are converted to PDF using AFP2PDF transform.

Going by your idea, do you know how can I convert the AFP into PDF before starting the ingestion process?
Can I somehow use the afp2pdf transform on my AIX server before I start ingesting the file using PDF indexer or generic indexer?

Title: Re: Pagination
Post by: kbsiva on August 01, 2013, 10:28:36 AM

Hello Pankaj,
 If you have infoprint manager you can convert AFP to PDF and vice versa on your aix server.

Thanks,
Siva

Title: Re: Pagination
Post by: Justin Derrick on August 02, 2013, 07:20:51 AM

Standard procedure when retrievals are going to take a long time (conversion or retrieval delays) is to tell the user to check back later for their converted / retrieved file.

The alternative is to convert everything, and cache it.  That may take a considerable amount of time and disk space, and might even represent a security problem.

The only sneaky/creative method I can think of is...  If the user only searches for a small subset of documents (ie, one login == one customer number) you could retrieve and convert the last X months of data in advance, and cache it for 24h or so.

Let us know how you solve this one...

-JD.

Title: Re: Pagination
Post by: pankaj.puranik on August 02, 2013, 09:08:00 AM

These are actually daily trade confirmations. We have some accounts whose trades for a given day exceed 2000 pages.

So I think we will have to convert the big files into PDF and load them.
I need to figure out how this could be done. But it seems like this is the only solution.

However, when you say "you could retrieve and convert the last X months of data in advance, and cache it for 24h or so"; I am not sure how to do this.
Any pointers?

Title: Re: Pagination
Post by: ewirtz on August 05, 2013, 01:01:18 AM

Hi Pankaj,
just an idea. If you have something like 'page nnnn' on every page, you could configure another break for instance 'page nn'. By this you will get an additional break every 100 pages. Maybe this helps.

regards Egon

Title: Re: Pagination
Post by: pankaj.puranik on August 09, 2013, 09:24:57 AM

Thanks Egon.
These are AFPs with TLEs, soI really don't have that option.

Title: Re: Pagination
Post by: ewirtz on August 12, 2013, 03:41:26 AM

Hi Pankaj,

another option is to use an index exit. You define an additional field p.e. portion and you fill it with a default. The index exit is used to change the default to generate document breaks.

regards

Egon

Title: Re: Pagination
Post by: jeffs42885 on October 29, 2013, 06:45:16 PM

Not sure if this would apply in this situation, but what about enabling fast web search in your afp2pdf settings. (a2pxopts.cfg)