Brief Overview of Service Data Objects This page last changed on Nov 28, 2008. .stickable, h1, h2, h3, h4, h5 false true Show Sticky notes Hide Sticky notes Save Cancel Oracle Data Service Integrator Documentation > Data Services Developer's Guide # Test Update Procedures Using SDO Data Graphs This topic is a brief overview of Service Data Objects and data graphs, which you use to test update procedures in Workshop for WebLogic. Key Points Updates in Test View Optimistic Locking See Also ## Key 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. ## Updates in Test View When you test an Update procedure in Test view, you are actually updating a Service Data Object (SDO) from within Workshop for WebLogic. ##### Selecting an Update Procedure 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. ##### A Data Graph with Old and New Data
    <sdo:datagraph xmlns:sdo="commonj.sdo">
      <changeSummary>
        <sim:SIMPLE_CUSTOMER sdo:ref="#/sdo:datagraph/sim:SIMPLE_CUSTOMER" xmlns:sim="ld:logical/SimpleCustomer">
          <CUSTOMER_SINCE>1999-01-01T00:00:00</CUSTOMER_SINCE>
        </sim:SIMPLE_CUSTOMER>
      </changeSummary>
      <sim:SIMPLE_CUSTOMER xmlns:sim="ld:logical/SimpleCustomer">
        <CUSTOMER_ID>CUSTOMER7</CUSTOMER_ID>
        <CUSTOMER_SINCE>2007-11-11T00:00:00</CUSTOMER_SINCE>
      </sim:SIMPLE_CUSTOMER>
    </sdo:datagraph>
## 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. ## See Also ##### How To Test an Update Procedure Enable Optimistic Locking in Relational Objects ##### Concepts Data Programming Model and Update Framework (in depth, for client applications)

Document generated by Confluence on Jan 13, 2009 15:57