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.
In this case, the formatting of the target URL is unusual:
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:
The standard HTTP:// 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.