Data Services Developer's Guide
|
 |
 |
|
 |
 |
You can use Test View to execute any data service read or relationship function for which data is available.
When you run a query in Test View results appear in an editable window in text or structured XML form. When updates are available for your data, you can immediately update your back-end data. Query results can also be used as complex parameters for other queries.
In creating support for query functions, BEA Aqualogic Data Services Platform (DSP) determines Test View options from your query function's signature. Three types of query function signatures are supported:
Query Plan View is also described in this chapter.
The following major topics are covered in this chapter:
In Test View you can select any of the read or navigation functions defined in your data service from a drop-down list.
Figure 7-1 Test View Options for a Function Accepting a Simple Parameter
If the query accepts complex parameters, the parameter entry dialog automatically adjusts, as shown in Figure 7-2.
Figure 7-2 Function Accepting a Complex Parameter As Input
To use Test View, follow these steps:
You can review instructions generated by your query in the Output window. See Reviewing Query Performance for details.
In the case of a query such as getAllCustomers(), no parameters are needed (Figure 7-3).
Figure 7-3 Query Without Parameters
When you click Execute the query will run.
Results are returned in text or XML form. Click on the + next to a complex element (in this case, a table representation) to see more detailed results.
When you have appropriate update permissions — as is commonly the case with "sand box" testing — you can directly edit results. For example, you could change a customer ID.
Figure 7-4 Editing query results
When you are satisfied with the changes click Submit.
When your query requires one or multiple simple parameters, Test View display each parameter in its own field, identified by name and type. The query function will be listed with a parameter as in:
getCust(CustNum, CustName)
Figure 7-5 Function with Two Input Parameters in Test View
See Running a Query With No Parameters on page 7-4 for details or executing a query and editing and submitting results.
Enterprise-scale queries often require a complex parameter type as input. For example, an inventory query may require a set of parameters which are based on a web service supplying a list of orders received. It is easier to just pass the entire object than to specify a large set of individual parameters.
When your query requires a complex parameter, the query function will be listed with a parameter as in:
getProfileView(arg)
The arg parameter indicates that a complex parameter type is needed.
For such parameters Test View displays a box (Figure 7-2) into which you can:
In any given data service you can use results from a previously run query as input. This is particularly useful when invoking navigation functions, since navigation functions always require complex parameters.
Note: When pasting prior results it's important to keep in mind that queries returning multiple results (arrays) cannot be input to functions looking for a single object as a parameter. For example, a function that gets orders for a particular customer is likely to return multiple orders. Those results cannot be used for a function that returns information about a particular customer.
The following steps show how results of a singleton query can be repurposed as input for a complex parameter.
Figure 7-6 Executing a simple parameterized query
Figure 7-7 Using Query Results in a New Query
Note: Your results have been returned as a singleton element in an array (highlighted in blue in Figure 7-7). The array element needs to removed before you can successfully execute your navigation function.
<ns0:ArrayOfELEC_ORDER xmlns:ns0="urn:retailerType">
<ns0:ELEC_ORDER TYPE="ELEC">
<OrderID>ORDER_1_0</OrderID>
...
</ns0:ELEC_ORDER>
</ns0:ArrayOfELEC_ORDER>
<ns0:ELEC_ORDER TYPE="ELEC" xmlns:ns0="urn:retailerType">
<OrderID>ORDER_1_0</OrderID>
...
</ns0:ELEC_ORDER>
Figure 7-8 Complex Parameterized Query Results
You can also automatically enter a template of the XML type of your data service. In Figure 7-9, a customer ID (CUSTOMER3) and order ID (ORDER_3_0), are provided through the template. Results are also shown.
Figure 7-9 Using XML Type Template to Guide Data Input
Template parameters are ideal when you know the key parameters required by your query.
You can filter query results through Test View to n instances of a single element. For example, the first five customers from an array of 5,000.
Figure 7-10 shows a function where the results for RTLServices/Customer/getCustomer() are limited to three. Without the limitation, all 10 customers are returned.
Figure 7-10 Limiting Elements in an Array Result
The Client Transaction Option supports functions that query more than multiple (two or more) relational sources using XA transaction drivers. By default this option is not selected, meaning that the NotSupported EJB transaction method is used. If the option is checked, the Required transaction mode will be used instead.
For general information on the subject see Transactions in EJB Applications BEA WebLogic Server documentation.
Test View results are validated against the data service's schema file when the Validate Results checkbox (shown in Figure 7-10) is selected. When active the following conditions will be flagged as invalid:
Invalid results are reported in the Output window. Such results can be addressed by correcting the return type or associating the return type with a new, corrected schema. See Validating and Saving Your Return Type.
Notes: Whenever you attempt to edit results of a query, those results are re-validated. The criteria is the same as that used for the Validate Results option.
Results are validated by calling the XMLBean validate() method, currently documented at the following URL:
http://workshop.bea.com/xmlbeans/reference/com/bea/xml/XmlObject.html#validate()
An executing query can only be ended through the Data Services Platform Console or by ending your server process. However, you can start a new query by changing your selection in Test View. Performance may be affected.
When a query function is invoked through Test View performance information appears in the WebLogic Workshop Output window (View
Figure 7-11 Function Query Output Windows Results
Two types of information are available to help you analyze the design and performance of your query.
Query Plan View is designed to help you understand how a query is designed.
The returned plan identifies the following query components:
Figure 7-12 Query Plan Fragment for RTLApp's Customer Data Service getCustomerByCustID(cust_id) Function
There are several ways that a query plan can be viewed:
The following query is from the Data Services Platform RTLApp: (RTLServices/OrderDetailView/getElecOrderDetailView(order_id, customer_id)
From the function signature you know that the query returns data related to order details after it is passed an order ID and a customer ID.
for electronic orders matching CustomerID and OrderID
return order information and ship-to information
for credit card information matching an AddressID
return credit information and bill-to address information
for electronic line item information matching the line item in the order
return line item information
A compressed version of the query plan is shown in Figure 7-13.
Figure 7-13 Query Plan for getElecOrderDetailView()
The let statements represent mappings or projections in the data service. This can be useful when trying to trace performance issues.
The join conditions are identified in the plan as a left-outer join driven by a complex parameter. By definition, joins have left and right sides, each of which can contain additional joins. One of the best uses of the query plan is to see how the query logic works up the various data threads to return results, as shown in Figure 7-14.
Figure 7-14 Top Down Schematic of getElecOrderDetailView() Function
Two options are available in the Query Plan.
See Reviewing Query Performance.
|
|
|
