7 Testing Update Procedures Using SDO Data Graphs

This chapter is a brief overview of Service Data Objects and data graphs, which you use to test update procedures in Eclipse for WebLogic. This chapter contains the following sections:

7.1 Key Points

Remember these points:

  • To test an Update procedure in Test view, you must submit a data graph as an argument.

  • A data graph is an XML structure that contains the data you are changing, as well as the original data.

  • When you update a relational data source, Oracle Data Service Integrator uses optimistic locking. The data source is locked at update, not when the data is initially retrieved.

7.2 Updates in Test View

When you test an Update procedure in Test view, you are actually updating a Service Data Object (SDO) from within Eclipse for WebLogic.

Figure 7-1 Update in Test View

Select update procedure.
Description of "Figure 7-1 Update in Test View"

SDO is a programming model for Java platforms that unifies data programming across many types of data sources. SDO is based on data objects, which are simply object instances that contain data. You can update the data objects using either static or dynamic data APIs. With a static API, the shape of the data is defined in advance. However, with a dynamic data API, you can update properties at run time that are not known at development time.

The SDO model is based on data graphs, which are collections of tree-structured data, usually XML. A client retrieves a data graph from a data source, modifies it, and applies the data graph back to the data source.

A data graph contains a <changeSummary> element with the original data you are updating. It also contains an XML element with the new data. When both the old and new data are passed back to the data object, the object can be updated.

Example 7-1 A Data Graph with Old and New Data

<sdo:datagraph xmlns:sdo="commonj.sdo">
    <sim:SIMPLE_CUSTOMER sdo:ref="#/sdo:datagraph/sim:SIMPLE_CUSTOMER"
  <sim:SIMPLE_CUSTOMER xmlns:sim="ld:logical/SimpleCustomer">

7.3 Optimistic Locking

When an SDO updates a relational source, it uses optimistic locking to avoid change conflicts. With optimistic locking, the data source is not locked after the client acquires the data. Later, when an update is needed, the data in the source is compared to a copy of the data taken when it was acquired. If any of the underlying data was changed before the client applies the changes, the update is rejected, and the client must recover.

The optimistic locking policy is set for each relational data source.