text/html) using either Java or Web Server Agents, or manually at design time if not otherwise possible.
Injecting Agents is what instruments a web site. Injection consists of:
- Initialization code. It is an inline
- Injecting a tag with a
Injected Agents use configuration settings in the System Profile - User Experience item, generically:
<featurehash>: A set of characters that identifies which Agent modules to include and activate. When only the basic Agent is activated, the feature hash is empty resulting in two adjacent underscores in
dtagent__<version>.js. The following modules are delivered with AppMon:
Ajax (XHR) detection modules:
- ActiveX XHR Detection (v)1
- Angular JS (g)
- Basic XHR Detection (x)
- Dojo (d)
- ExtJS (e)2
- ICEfaces (i)
- jQuery (j)
- MooTools (m)
- Prototype (o)
- Perceived render time (p)
- Speed Index (S)
- Streaming (s)
- Timed Action Support (t)
- User Timings (T)
- Visually Complete (V)
Community packs (debug mode only):
- Gomez page and group IDs (z)
- JS agent async core module
- JS agent initconfig module
- Windchill (1)
2 Some ExtJs-Functions use deferred callbacks when they send XHRs. AppMon does not capture these requests because it can't create a link to a user action. Activate the Timed Action support To avoid this, activate the Timed Action support. It extends user actions to track deferred functions. Ext.FormPanel is a known ExtJs function that must have Timed Action (t) support.
How does it work?
After UEM configuration changes, the initialization code is created containing all necessary information about the current configuration for each application. It can then be retrieved using the REST API.
- Overhead: Since the initialization tag is inlined into a page, there's no additional request that has to be made by the browser. The configuration updates are retrieved as soon as an action is sent.
- Filesize: Depending on the application configuration the obfuscated initialization code's size is about 6.65kb.
- Browser support: Internet Explorer 6 and 7 have no implementation of Local or Session Storage and therefore do not automatically update upon configuration changes. However, as soon as the cached page ages, the initialization code updates to the latest configuration revision.
There are various ways the initialization code is executed, depending on the visitor.
Monitor signal behavior
In most cases signals are sent as soon as actions are finished. This action starts with a user input that triggers a request and ends as soon as all of the request's callbacks are finished. The load-action occurs on each iframe and full page load and is sent on every page, if user inputs exist or not.
These actions trigger signals to be sent immediately after the actions are finished, in contrast to medium priority signals. These are triggered by timeless and lesser important actions. These medium priority actions are bandwidth, streaming, and resource information, as well as reported values like errors or custom strings. If a signal is queued, this information is appended and doesn't create a separate request.
If multiple actions happen in a small time frame, such as a user action during page load, all of those actions are sent in a single signal.
For longer actions, a preview signal is sent as medium priority signal. Actions are sent only if all of their children and siblings are finished. If, for example, an action is opened and a second one is opened (which automatically is a child of the first one), the first one won't be sent until the second one is finished.
Support for cross-origin resource sharing (CORS)
Reporting from a non-instrumented host
To enable support for CORS, start the AppMon Client and select the Send AppMon monitoring request to foreign domain in [System Profile] > User Experience vertical tab > [application] horizontal tab > Advanced configuration section.
Be sure to set the Monitor request path configuration to a location (use an absolute path that starts with
http) that is UEM-enabled (for example by a Java Agent).
Monitoring CORS requests
Web requests can only be linked to user actions if cookies are available. In case of CORS requests, cookies aren't sent per default. Therefore correlation between user actions and CORS web requests can only be achieved by using the withCredentials property of the XMLHttpRequest object. This applies for an environment like this:
Due to access-control-restrictions it is not possible to capture OPTIONS requests like those sent as CORS preflight requests. Capturing those requests would require sending a AppMon cookie to the receiver of the request, which is not allowed. This could result in User Action PurePaths that have the correct timing values, but are missing the time the OPTIONS request took before the real CORS request fires. See MDN for more information about CORS preflight requests.