One of the frustrating parts when you first start developing on BMC Remedy is seeing changes you make in Developer Studio show up in the middle-tier browser session. As part of it's optimization, Remedy does a good job trying to anticipate your needs and tries to cache everything it can. However, knowing the proper want to clear the cache can be illusive, and down right vexing. This documents outlines the fastest way to do so, especially important on your dev/qa systems (where you do this work right... you aren't doing this on your production systems!!)
This document has been drafted for ARS and mid-tier versions 8.x, but should be backward compatible to v6.
Step 1 - Save your changes in Developer Studio
OK, seems like a no-brainer. But make sure your code changes are actually saved out. It is easy to forget this, especially when working with form overlays of existing components that may take sometime to save if their are warnings are on the page. As an example, if you look at the Help Desk pages, it could take several minutes before it completes and shows the dialog with its success (and warnings). So ensure you have completed this BEFORE you start any cache modifications.
Step 2 - Flush the midtier cache
Once you are ready, head to your Remedy server and flush the cache. You can find this at:
It may be useful to bookmark that page, or consider script automation to go there. Once there click the "Flush Cache" button. This will clear the Remedy side of the equation.
If you decide to use script automation to flush the cache there are two different articles within BMC Communities of value on this subject:
If you ask me, the cleanest way would be to build a script to call into it, and then call into the browser cache flush (to be shown later in this document). Using Sylvain YVON wget technique, it would look something like this:
wget --cookies=on --keep-session-cookies --save-cookies "/tmp/cookies.txt" "http://<server>/arsys/shared/config/config.jsp"
wget --cookies=on --keep-session-cookies --load-cookies "/tmp/cookies.txt" --save-cookies "/tmp/cookies.txt" "http://<server>/arsys/servlet/GoatConfigServlet?action=logon&password=<pwd>"
wget --cookies=on --keep-session-cookies --load-cookies "/tmp/cookies.txt" --save-cookies "/tmp/cookies.txt" "http://<server>/arsys/servlet/GoatConfigServlet?action=Cache&cache_flush=Yes"
Step 3 - Flush your browser cache
Once the midtier is cleaned out, you will need to flush the cache on your browser. Depending on which browser you use, in many cases normal flushing doesn't guarantee this will work correctly. So below is some guidance on ways to flush the cache on some of the more popular browsers you will use during development.
Chrome stores its data in a per-user application data dir that you can find at:
The easiest way to get rid of the cache data is to erase everything there on your dev systems. When Chrome loads, it will see its missing, and recreate it. So a simple batch script may be something as simple as:
set ChromeDir=C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data
del /q /s /f "%ChromeDir%"
rd /s /q "%ChromeDir%"
You could then launch Chrome (maybe from the script) and use cmd line params to point the cache there (or elsewhere). In any case this ensures the cache needs to be rebuilt as you log into Remedy.
IE is a bit trickier, as it stores data all over the place. Getting right to it, consider a script such as:
del /q /s /f "%DataDir%"
rd /s /q "%DataDir%"
del /q /s /f "%History%"
rd /s /q "%History%"
del /q /s /f "%IETemp%"
rd /s /q "%IETemp%"
del /q /s /f "%Cookies%"
rd /s /q "%Cookies%"
REG DELETE HKCU\Software\Microsoft\Internet Explorer\TypedURLs
Notice the need to delete both files on disk and the registry. This is because cache URLs are treated differently. If you don't delete the registry, the physical files are gone, but IE doesn't know to refetch the data right away. It's not needed, but it will speed up the need to pull all data down.
Firefox stores all its data in two distinct places. The first is per-user appdata, and the second is in a roaming profile where they use sqlite databases. The locations are as follows:
So a script to properly flush Firefox may look something like:
del /q /s /f "%DataDir%"
rd /s /q "%DataDir%"
for /d %%x in (C:\Users\%USERNAME%\AppData\Roaming\Mozilla\Firefox\Profiles\*) do del /q /s /f %%x\*sqlite
Step 4 - Pray to your $DEITY$ and login
Well, assuming everything worked right at this point you will login with your dev account (or Allen and Mary if you are using the normalized test data set) and should notice a delay as Remedy repopulates your cache. That's a good thing... so go grab a coffee while it does its work.
At this point you should be able to go to the area where your overlay is that you are working on, and see the changes. If you don't, there are few things to ask yourself:
- Did you remember to set the permissions on the UX elements you are working with?
- Does the logged in user have those perms?
- Did you really follow the guidance above to flush the cache?
- Did you really completely close your browser. Seriously. Is there a chance another windows is somewhere on another monitor?
- Is the browser using a proxy? If so you may need to set an exclusion from your dev systems so that you don't use a proxy cache.
- Is a load balancer in play? If so you may need to configure it to route your dev systems to a specific instance to ensure containment and consistency in data load.
For the record, when doing rapid dev there is a chance you will miss one or all of the above at least once. I know I did. But if you script the browser launch and include the above ideas for cache flushing, and remember to flush the middle tier... you should be good to go.
Don't trust the cache. Even when you do the above, a single window still open or a bad flush could have you chasing ghosts as you develop. One consideration is to make sure you msg / notify on the front end somehow and show a version number or some other identifying mark so you know new code has been loaded. This is really important when you make changes that have no other visual changes... like when working on Active Links and backend web service code. A simple updating label or notification message might just save you time and agony.
And don't make front end changes a lot. Loading the cache is a pain. So try to iterate in a way so you don't have to do that. It just makes common sense.
Hardcore Developers should consider having a Remedy Windows client available to test with. There will not be new clients written for v8+, but the v7.6.04 client should be backward compatible for sometime. It is especially useful for testing UI components (v7.6.04 and earlier) and for user workflow logging; do not rely on it to validate new features (v8 and above, nor non-remedy components such as flash).
You may have remembered to flush the cache. But did you remember to do it on both sides? When first starting to work with Remedy it is easy to forget how long it takes for changes to appear in the midtier. Following this guidance will remove a lot of the headaches. And hopefully no one else will go through the pain I went through when first trying to get the dev done.
BONUS - Dana's Flush Script
In case you are too lazy to read through everything and apply it yourself, below is the working script I use to do my dev work. Remember this is on a dev instance I control of Remedy, and MAY NOT be suitable for a shared environment.
SET WGET="C:\Program Files (x86)\GnuWin32\bin\wget.exe"
SET CHROME="C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe"
SET CHROMEDIR="C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data"
%WGET% --cookies=on --keep-session-cookies --save-cookies "C:\Windows\Temp\bmc_cookies.txt" --delete-after %REMEDYSRV%/arsys/shared/config/config.jsp
%WGET% --cookies=on --keep-session-cookies --load-cookies "C:\Windows\Temp\bmc_cookies.txt" --save-cookies "C:\Windows\Temp\bmc_cookies.txt" --delete-after "%REMEDYSRV%/arsys/servlet/GoatConfigServlet?action=logon&password=%MTPWD%"
%WGET% --cookies=on --keep-session-cookies --load-cookies "C:\Windows\Temp\bmc_cookies.txt" --save-cookies "C:\Windows\Temp\bmc_cookies.txt" --delete-after "%REMEDYSRV%/arsys/servlet/GoatConfigServlet?action=Cache&cache_flush=Yes"
del /q /s /f %CHROMEDIR%
rd /s /q %CHROMEDIR%
%CHROME% --disable-application-cache --disable-popup-blocking --no-autofill-for-password-generation --new-window %TARGETURL%
A few comments on the above:
- You need to install wget, an open source tool, from http://gnuwin32.sourceforge.net/packages/wget.htm
- You need to ensure wget uses --delete-after to clean up the tmp files downloaded
- Storing cookie data in Windows\Temp is a security risk, since anyone can access it. I am ok with this, because its a dev VM. You may decide to use a more protected directory and ACL it accordingly
- Make sure you update REMEDYSRV, MTPWD accordingly
- Use Target URL. Instead of fretting about all the pre-caching on first login, you can point it directly to the object in question. In my case I point directly to the form overlays I am working on.
Once saved, this batch file sits on our dev VMs on the desktop. We can then close the browser, double click the batch file, and it flushes everything, and takes us to the page we are working on. Since we are making changes several times an hour, this is the only way keeping us sane, and Remedy working in any sort of respectable way for our dev workflow.
HTH. Have fun!