Resource Request Trace Tool

The Resource Request Trace Tool allows you to inject arbitrary resource requests into a module.

The tool is very easy to use. Simply select a deployed module from the drop down list, enter the URI address you are testing into the "URI" field, select either "External" or "Internal" injection and then press the "Resolve" button to trace the address resolution phase or the "Resolve and Execute" button to both resolve and request the resource.

Usage Scenarios

The request trace tool is used to probe and test an application's resource address space. It is very helpful to use the trace tool in the following situations:

• To see that a module is correctly deployed.
• To test the public interface of a module when it is created/modified.
• To test internal module resources are correctly mapped into a module's address space.
• To test that a service is correctly mapped into a module's address space
• To test that a modules imports are providing the correct services.
• To test that mapping from a public to private address is correct.

In brief, its good practice to use the trace tool to probe the address space as you develop. Typically in development a module and its address space are continually being changed. The trace tool should be used to check that changes are correct and that the routing of the application address space is well defined.

Internal Injection

As described in the module overview section of the Solution Developer Guide a module contains a internal private address space. This address space is empty until entries are made in the mapping section of the module definition file (module.xml).

By using the internal request injection option you can issue a resource request directly into the private address space of the selected module and test that your entries work as you planned.

Example

Using the tool, select the module urn:org:ten60:workbench. Select Internal injection, enter the URI ffcpl:/index.html and press the resolve button. You will see the following trace:

which shows that the resolution is searching for ffcpl:/index.html within the module urn:org:ten60:workbench and is matched on a this mapping rule specifying the regular expression ffcpl:/.* (the entire ffcpl:/ address space). This test proves that the private internal address space contains a mapping that matches the address provided, but it does not prove that the specific resource exists. To test for that we need to use the "Resolve and Execute" option.

Next press the "Resolve and Execute" button to perform both phases of the request. You will notice that this time the tool provides additional information about the resource representation including the creation cost, expiry, etc.

Example

In this example we will use an address that does not resolve. With the same settings used above, enter the URI address active:foo. When you press the "Resolve" button you will see a trace similar to the following:

Notice that the trace fails to find a match within the module and then tries all imported modules. Those fail to resolve also resulting in the last line stating "No Match Found for active:foo".

External Injection

A module may export portions of an address space by including entries in the export section of module definition file.

The exported address space may be tested by using the "External" request injection options.

By using the external request injection option you can issue a resource request at the outer boundary of the module and test if the request is accepted and resolved within the module.

Example

Using the tool, select the module urn:org:ten60:workbench. Select External injection, enter the URI ffcpl:/index.html and press the resolve button. You will see the following trace:

which shows that the requested address does not match any of the entries in the export section of the module definition file.

Example

Next use the URI address ffcpl:/workbench/index.html and press the "Resolve" button. You will see the following trace:

which shows that the requested address does match the exported address space and matches internally. (With the workbench it is not possible to construct an example that will match on the exported address space and not resolve internally. This is a good thing as it shows that the module will resolve any request it accepts.)

This example also illustrates that having a module export only a portion of the ffcpl:/ address space is a good standard of practice. With an application built from multiple modules, one of the design responsibilities is partitioning and mapping address spaces to modules.