The XML Mapping Utility includes features for verifying inbound and outbound messages generated using a rules file. The entire test sequence consists of executing outbound mappings, generating the outbound message, sending the message, receiving the response, and executing inbound mappings. Outbound and inbound filtering logic can also be entered and verified.
 | The XML Mapping Utility supports one-way (request) and two-way (request/response) messaging for WSDLs. An example of a one-way message is a delete operation sent to the server. |
Setting Up a Test
To set up a test, specify values for each mapped element to simulate user input. There are two ways to simulate input:
- Specify data in user input fields in the work area.
- Specify values in the Mappings table.
To specify values in the Mappings table, complete these steps in the XML Mapping Utility:
- Select a rule in the Rules Tree panel.
- In the Mappings table of the Settings panel, select Script from the drop-down list in the Type column.
- Type the JavaScript setValue function in the Path/Value column and specify a value, setValue("value_") ;
The setValue() method is useful for specifying constants normally specified by a user at runtime or a value that is calculated from user input.
- When all values are specified, click the Save button.
Running a Quick Test
To test your mappings in the rules file, complete these steps:
| This section uses the General Interface WSDL Mapping 2 sample located in workspace/JSXAPPS/samples/WSDL_Mapping_2. By default, this sample runs in Static Mode, rendering the results of a sample message on screen. To run against the Xignite web service in Live Mode, register for a license key at http://www.xignite.com/xhistorical.asmx?op=xRegister. Then set the project to Live Mode on the Deployment panel of the Project Settings dialog (Project > Project Settings > Deployment) and reload your browser. |
- In the application work area, appCanvas.xml, simulate user input by entering data in the application.
For example, enter stock symbols in the WSDL Mapping 2 example and choose a date.
- Select an operation rule, such as GetHistoricalQuotes, in the Rules Tree panel of the XML Mapping Utility. Right-click the rule and select Execute (Quick Test).
When the response is received, a file with the specified name displays in the Local Data Cache palette. This file exists in the cache instance used by the current component. In the WSDL Mapping 2 example, the file name in the Local Data Cache palette is historicals. If you open this file, you'll see the response data from the service.
- Return to the work area to see the updated information in the mapped component. If the updated information isn't displayed, complete these steps:
- Select the top-level GUI component that consumes the data in the Component Hierarchy palette.
In the WSDL Mapping 2 example, select the gridResults component.
- Click the Repaint button
in the Component Hierarchy palette.
Test Interface Tool
To use the Test Interface Tool, click the Test button 
on the Rules Tree panel toolbar. The Test Interface Tool displays.
The Test Interface Tool is designed to guide you through the test sequence. The Create, Send, Receive, and Apply tabs correspond to phases of sending and receiving XML messages. Clicking a tab displays data that is relevant to the current test phase.
Before running a test, you can set breakpoints at various steps in the test sequence or you can also test a rules file without breakpoints. For more information, see Setting Breakpoints.
Mapper Log
You can also use the Mapper Log to view the results of a message exchange. Use the Adjust Log Level button 
to select a log level before you begin testing.
Running a Test
To run a test in the Test Interface Tool, complete these steps:
- Click the Test button on the Rules Tree panel toolbar to open the Test Interface Tool.
- Select the operation to test from the Select drop-down list at upper left.
Click here to expand screenshot...
The Create tab displays in the Test Interface Tool.
Click here to expand screenshot...
The Create tab displays mappings for the outbound message and the following fields:
- Rule Name contains the name of the element.
- Type shows the type of object that is mapped.
- Path/Value contains the GUI component name or any associated JavaScript code for this mapping.
- Post-Mapping Filter/Handler contains filter code to execute before sending the message.
- Click the Start Test button
next to the Outbound Mappings label to start the test. If you didn't set any breakpoints and there aren't any errors, the test runs and cycles through each tab: Send, Receive, and Apply. When the test is complete the Create tab displays again.
- If a breakpoint was set, the test advances to the Send tab. For more information, see Setting Breakpoints.
Click here to expand screenshot...
The Send tab displays the outbound message and the following fields:
- URL contains the URL specified in the WSDL file.
- HTTP Headers contains header content for the message. The header text can be customized by editing this value.
- Name and Password are used for services requiring HTTP authentication.
- Method defines the method for contacting the Service. The most common are GET and POST.
| The contents of the outbound and inbound messages can be saved to local files for testing purposes. By mapping the saved inbound file and specifying the application mode as Static on the Deployment panel of the Project Settings dialog (Project > Project Settings), you can continue developing your application without a data service connection. For more information, see Deployment Panel. |
- If a breakpoint was set, click the Resume button to advance to the next step. The outbound message is sent to the data service, and the response is displayed in the Receive tab. Because the Receive tab doesn't have a breakpoint, the test continues to the Apply tab. Click the Receive tab to see the response.
Click here to expand screenshot...
The Receive tab displays the following fields:
- HTTP Headers contains the HTTP headers.
- HTTP Status contains the message status, such as 200.
- Response contains the response.
If the response isn't received, testing can still proceed with a simulated response message. Click the Generate Alternate Inbound Message button 
to the left of the Response field. A response message for the specified operation is copied to the Response field.
- If the Test Interface Tool doesn't automatically advance to the Apply tab, click the Apply tab to advance to the next step.
Click here to expand screenshot...
The Apply tab displays the following fields:
- Pre-Mapping Filter/Handler contains filter code to execute on the inbound document.
- Inbound Mappings contains mappings of response rules to GUI components and inbound filtering logic, if any.
This is the final step in the testing process. If filtering logic and mappings executed without errors, the Create tab displays to allow you to start another testing cycle.
For a step-by-step example of running a test with the Address Lookup example, see Testing Mappings.
Setting Breakpoints
Before running a test, you can set breakpoints for viewing request and response messages at each step in the process. Breakpoints can be set at the following steps:
- Before applying filtering code, if specified, to the outbound message
- Before sending the outbound message to the data service
- Before applying filtering code, if specified, to the inbound message
- Before executing inbound mappings
You can also test a rules file without breakpoints. However, it is usually helpful to view the test results after each step. When advancing from one breakpoint to the next, you can return to the previous breakpoint to retest only that step in the process. After modifications to mapping rules, changes can be tested from the last breakpoint.
To set a breakpoint and run a test with breakpoints in the Test Interface Tool, complete these steps:
- Click any tab that displays a Breakpoint button
, such as the Create, Send, or Apply tab.
- Click a Breakpoint button to set a breakpoint.
- Click the Create tab and run the test as described in Running a Test. The test stops at any step that has a breakpoint set.
- Click the Resume button to advance to the next step.
Setting Filters
Filters can be applied to messages before an input message (request) is sent or after an output message (response) is received and before the mappings are applied. This is useful when you want to modify requests and responses.
You can enter JavaScript code to run as a filter on message rules. There are two ways to set a filter for message rules:
- Input message rules
- Post-Mapping Filter/Handler field Enter JavaScript code in this field on the Create panel of the Test Interface Tool to filter the input message during testing.
- onBeforeReceive field Enter JavaScript code in this field of the Settings panel of the XML Mapping Utility. Code entered in this field is always run on the message. Note that code entered here is also automatically displayed on the Create panel of the Test Interface Tool and runs during testing.
- Output message rules
- Pre-Mapping Filter/Handler field Enter JavaScript code in this field on the Apply panel of the Test Interface Tool to filter the output message during testing.
- onAfterReceive field Enter JavaScript code in this field of the Settings panel of the XML Mapping Utility. Code entered in this field is always run on the message. Note that code entered here is also automatically displayed on the Apply panel of the Test Interface Tool and runs during testing.
Filters are useful for manipulating input and output messages as they travel between the client and the server. For example, the XML Mapping Utility doesn't support multiRef structures that are sometimes used to describe SOAP messages on Apache Axis servers. However, you can use the onAfterReceive event handler to manipulate the output message from the server before running the inbound mapping rules. Since you can't control your server environment, you could write an XSLT that would convert the multiref indirection to a supported XML Mapping Utility format. This transformation would occur on the client after the message is received. For more information on this multiRef example, see onAfterReceive multiRef Example.
Further Information
For more tutorials and sample applications, see:
