Grease up those hands

An important piece in the way IAG works is called URL signing. This process involves the server adding a string of seemingly-random characters to links. The string is not random at all, really, and the purpose of this is to allow IAG to communicate with many internal servers, while using just one IP and Port externally. Since the requests from the client all come-in on the same port and IP, but are destined for one of (possibly) many internal servers, IAG recognizes to which server to direct the request based on the unique "signature". For example:

The process that goes on back-stage is that the IAG Engine, as it reads a page from the back-end server and passes it along to the end-user, looks for links in the HTML code, and matches them to internal servers that it "knows" about (because they appear in the configuration of one of the applications). It then changes the links and adds the unique key assigned to that application. Later on, when the user clicks on one of the signed links, the IAG parses the URL and knows from which internal server to fetch the data.

This is all nice and neat under normal conditions, but  the process of locating the links in the HTML is not always so simple. One challenge is that sometimes, the links are built dynamically by JavaScript. For example, the script could concatenate the target URL like this:

In this case, the formatting of the target URL is unusual:
"/Point/com/composite.aspx?_DF=OMSm_NRTOtgSum_byOrg_T&Filter=5=TelAviv"

This prevents the engine from recognizing this is a URL, and so it gets passed on as-is. The result is that a link points to a non-existent URL, and an error is displayed to the end user.

The solution to this type of problems is to use a component of IAG called "SRA", and add a custom-tailored instructions that will let it recognize the malformed URL and "fix" it, so that it can later sign it properly. In this case, we would change it to something like:
" https://mapserver/Point/com/composite.aspx?_DF=OMSm_NRTOtgSum_byOrg_T&Filter=5=TelAviv"

The standard https:// prefix is all that's needed to let the magic happen. I will not go into detail on using SRA here, as it is well documented in the IAG User Guide, but I do want to talk a little more about a more complicated aspect of this. Sometimes, the code is so complicated that it's hard to determine where the offending function is. There is, however, a way to get better control by using a debugger.

No...don't be scared. I'm not talking about a 4-year course in writing software. In fact, one does not have to know JavaScript to do this - just a little common sense. The tool we would use is the Debugger included with Internet Explorer 8. Keep in mind that at this time, IE8 is not supported by IAG, so you will have to fire it in Compatibility Mode (Open the Tools menu, and select "Compatibility View Settings").

The next step is to go to the page that's before where the "bad" links are at and press F12 to open the developer tools. On that page, click "Script" and "Start Debugging". Next, click on "Break All", or press Ctrl+Shift+B on your keyboard. Now, the debugger is waiting, and as soon as ANY JavaScript is run, it will stop. Now, click on the link that brings you the problematic page (we do it this way, because the scripts often run at the time the next page load).

Now, once the scripts start running, the debugger will stop on a script line, and that's where the magic happens. On the right-hand part of the debugger screen, click "Locals", and that will show you the current variables. Now, use F11 to make the script continue, line-by-line, and watch the values of locals as they get created, assigned and discarded. At some point, you should see the problematic link being created and assigned to a variable. This would require some understanding of JavaScript, and fixing it is a whole other business, but this is how it's done.