04-10-2013 05:29 AM
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.
04-11-2013 09:15 AM
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.....
04-11-2013 10:20 AM
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.
04-12-2013 02:01 AM
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.