Some of you use TeamDesk as a back-end data management solution while extracting the content via SOAP API from the database to present on an front-end site, such as online shop. By the way, it’s a way TeamDesk promo site works; the list of applications and their categories is managed via TeamDesk application, and the promo site utilizes the API to obtain the info.
Let’s describe typical scenario: there is a Product table with Title, Description and Image columns; first two are a obviously a Text, and the last is Attachment.
To present the list of products with images in an HTML you typically need two pages. One will perform API’s Login() call, then Query() to get the list of products and then render Title and Description texts and HTML <img> tag referring to the second page. Second page will again perform Login() and GetAttachment() API calls and serve the binary data obtained from latter call as an image.
Suppose your product list page displays 100 products at once. How many API requests it will generate? It’s easy to calculate: there would be one Login()/Query() pair from the page itself and one Login()/GetAttachment() pair per product, resulting to 202 calls for each page view. Since each call generates network traffic and the network is a potential bottleneck, is there a way to reduce the number of calls?
Perhaps you can share API object between pages performing login once per session; this approach will cut the number of API requests in half; 102 requests exactly – one for first-time Login(), one Query() and 100 GetAttachment(). But is further optimization possible?
Let’s check what typical website visitor does. She reads the list of products (102 requests), then clicks on a link to see more of some product details (this will generate some more requests we are not interested in at the moment). If she’s not interested in the product she presses browser’s back button or clicks a link to return to the product list to check another product – and this generates yet another 102 requests.
Perhaps you can optimize product list page logic to perform Query() only when list changes, but this requires some relatively sophisticated logic and advanced coding skills. It would be much easier to cut the number of calls to an image-serving page down, or, better to say, you have a chance to remove image-serving page at all.
As you probably know, some time ago we have enabled public access to attachment files. If public access is enabled, the file is served to the user without a need to login. Our web page serving the file performs various browser cache checks and return file only if the browser does not have it cached or cached copy is out-of-date. And now you can utilize this page on your site.
If you include attachment column in your Query() call you’ll get back the file name and some additional info separated by semicolon, e.g:
filename;revision;uniqueidentifier
There are two pages in TeamDesk you can refer from your site:
https://www.teamdesk.net/secure/db/<app-id>/attachment.aspx
and
https://www.teamdesk.net/secure/db/<app-id>/image.aspx
First serves attachment file as is, second assumes the file is image and produces the thumbnail of specified width and height
Both pages accept two parameters:
fid is a number identifying the column. You can obtain this identified by visiting column’s page in the setup section and capturing the number following the string column= in the browser’s address bar.
guid is an uniqueidentifier, the text after last semicolon in the attachment string.
To generate the link to attachment file as-is that will be served directly from TeamDesk you’ll need to provide an URL to:
https://www.teamdesk.net/secure/db/<app-id>/attachment.aspx?fid=<column-id>&guid=<uniqueidentifier>
Image thumbnails are served in a similar way:
https://www.teamdesk.net/secure/db/<app-id>/image.aspx?fid=<column-id>&guid=<uniqueidentifier>&w=<size>
Last parameter specifies the size of the square box, in pixels, the image will be fit to. The aspect ratio of the image is preserved and resulting image will not exceed box dimensions; e.g. if you specify w=100 16×16 image will remain the same, 400×400 image will be downscaled to 100×100, 200×100 image will be downscaled to 100×50 and 100×200 image will be downscaled to 50×100.
