Creating Data Source Metadata 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 # Creating Physical Data Services by Importing Source Metadata In Oracle Data Service Integrator metadata around a particular data source is developed during the process of creating a physical data service. For example, a list of the tables and columns in a relational database is metadata. A list of operations in a Web service is metadata. In Oracle Data Service Integrator, a physical data service is typically primarily based on metadata describing the structure of those physical data sources. Physical data services are the building blocks for the creation of logical data services. ##### Data Source Support for Creating Physical Data Services
Source Type | Venue
--- | ---
Relational (including tables, views, stored procedures, and SQL) | JDBC
Web services (WSDL files) | URI, UDDI, WSDL
Delimited (CSV files) | File-based data, such as spreadsheets.
Java functions (.java) | Programmatic
XML (XML files) | File- or data stream-based XML
When information about physical data is developed during the creation of physical data services, two things happen: A physical data service (extension .ds) is created in your Oracle Data Service Integrator-based project. A companion schema of the same name (extension.xsd), is created. This schema describes quite exactly the XML type of the data service. Such schemas are placed in a directory named schemas which is a sub-directory of your newly created data service. ## Source View The introspection process is done through the Physical Data Service Creation wizard. This wizard introspects available data sources and identifies data objects that can be rendered as operations for either entity or library data services. Once created, physical data services become the building-blocks for queries and logical data services through a series of pragmas created in the query source. For example, the following source resulted from importing a Web service operation:
    (::pragma function <f:function xmlns:f="urn:annotations.ld.oracle.com" kind="read" nativeName="getCustomerOrderByOrderID"
    nativeLevel1Container="ElecDBTest" nativeLevel2Container="ElecDBTestSoap" style="document"/>:

    declare function f1:getCustomerOrderByOrderID($x1 as element(t1:getCustomerOrderByOrderID))
       as schema-element(t1:getCustomerOrderByOrderIDResponse) external;
Notice that the imported Web service is described as a "read" function in the pragma. "External" refers to the fact that the schema is in a separate file. For some data sources such as web services imported metadata represents functions which typically return void (in other words, these functions do something other than return data). Such routines are sometimes called side-effecting functions or procedures. The following source resulted from importing Web service metadata that includes an operation that has been identified as a side-effecting procedure:
    (::pragma function <f:function xmlns:f="urn:annotations.ld.oracle.com"
    kind="hasSideEffects" nativeName="setCustomerOrder" style="document"/>:

    declare function f1:setCustomerOrder($x1 as element(t3:setCustomerOrder)) as schema-element(t3:setCustomerOrderResponse) external;
In the above pragma the function is identified as "hasSideEffects".

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