Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Bronze Contributor
Posts: 125
Registered: ‎12-09-2010

Persisting large objects in the web client



I have a customer which uses webservices for the backend management.  Until recently they were using the Lan Client.  We're busy moving the functionality  to the Web Client.  One of the webservices returns a product catalog with all the available parameters and options for each product, its 10mb in size.  Is there a way in Saleslogix Web Client that the object could be called and persisted in some kind of global variables field, or would I have to store it in the browser's memory space?  What is the correct way of handling this?


I'm concerned that it might not be serializable, and if I need them to change the code, I will rather try convince them to seperate it into multiple smaller/faster functions than 1 single large one.


Any advice would be helpful.




Bronze Super Contributor
Posts: 129
Registered: ‎06-09-2009

Re: Persisting large objects in the web client

How often do you request the whole Catalog?


I believe Session Variables don't have a Limit, so you should be able to store this object there if needed, but make sure to clean up after you are done with it.


Another option could be to Store to a Temp file on the Drive or on a Temp Table in the DB.


And, if you don't refresh this data that often, maybe you can have a routine to Parse it into a Table(s) and then query it  based on Product IDs.....




Raul A. Chavez
Bronze Super Contributor
Posts: 236
Registered: ‎03-30-2009

Re: Persisting large objects in the web client

You could also place the catalog in the SLX Libaraies folder and make it available for download.  Storing something this big in session for each user is just asking for IIS to start crashing.

Mike LaSpina
Professional Services Consultant

8800 N Gainey Center Dr Ste 200
Scottsdale AZ 85258
Tel: 480-383-5344
Cell: 480-321-6637
Fax: 480-556-4090

Your Business in Mind.
Bronze Contributor
Posts: 125
Registered: ‎12-09-2010

Re: Persisting large objects in the web client

The customer is an ISP.   The catalog is unique per user/reseller and changes pretty often based on monthly specials and so on.  Its requested every time a new subscriber is created (Contact) so that their internet package can be configured, or when new services are added to an existing subscriber.


The catalog is maintained and managed in their backend ratings system.


Basically it returns a list of available products, each product has services (modem contracts, data bundles, static IP, mailboxes, Fax2Email, and so on).  And each service has parameters and parameters might have options, the type of data entry is dependent on its specified type.


Currently in the Lan Client I cache the object once a day per user.  I convert the XML to a flat structure in an ADO Recordset, and then serialize the recordset to a blob field.  Whenever the modifydate is older than 1 day, I call the webservice again.  The front end is dynamic and changes based on the information that comes with the object.  It might specify default services, the pricing, different options, whether a parameter accepts a string or displays a drop down or asks for a date or defaults to some information that might already be available in the system.


The recordset structure worked, because I could then assign it to a grid with hidden fields to hold options and triggers for the functionality, and a button field for specifying the value, and the button would dynamically call the relevant entry form.


But now with the web client I'm wondering if handling such a large object is a good idea.  Even if its cached rather than loaded from the webservice.  Its still something I'd have to constantly load back up again and interrogate between form posts.  And of course trying to cache the subscriber's options before sending them back to the webservices as part of the activation.  So I'm going to ask if they can instead supply several smaller webservices.  Like one that only has a list of products and one which returns services based on a product I send back.