3:02 p.m.
Moved from private thread to mailinglist:
Close, but in my model the user executes something more like this:
select t* from (EXEC getRequestXML(...)) as in, (EXEC execute(in) as out, (EXEC
getResponseValues(out) as t))
and in this case getResponseValues() is using XMLTABLE to create the procedure result. I
can also get a lot more complex if either the request or response requires hierarchy with
multiplicity, the it could become:
select t* from (EXEC getParentRequest((EXEC getChildRequest(...) as child), ...) as
parent,....
In regards to using access patterns on the inputs, I would only use them in the event that
multiplicity is >= 1. Real world WSDLs are pretty spotty in describing what's
actually required for a service and what's not.
~jd
----- "Ramesh Reddy" wrote:
John,
I am trying understand all this myself, as I am starting to write the
XMLTABLE blog. Yours is most advanced case in that!
For some reason, this model of two procedures, that user need to
execute
is not sounding right to me. So, let me understand this correctly.
User
executes some thing like this right?
select t* from (EXEC getRequestProcedure(...)) as in, (EXEC
getResponse(in))
Please correct me, if understanding is wrong.
thinking out loud - why not create response table based on the
response
XML using XMLTABLE and have access pattern on the all the scalar
input?
The one issue I see is input and output elements not matching.
Ramesh..
On Mon, 2010-08-16 at 10:13 -0400, John Doyle wrote:
> Hi guys,
>
> Last week I worked on changing the WSDL to source importer to work
with the new system functions. I've attached a model project that
contains a model for one operation of a WSDL in order to show the tact
I've taken, and want to get some feedback from you. It's not complete
yet, I need to add namespaces to the SQL, inputs/output for child
element XML, etc, but wanted to get feedback on the overall concept.
>
> The importer will create one physical model for each endpoint
defined in the WSLD, since each endpoint might need to be bound to a
different URL. I intended this physical model to used across the
generated views.
>
> The importer then creates a schema to contain views for each
operation. I added the schemas to the model because operations often
reuse the same type/element definitions across operations, but not
necessarily with the same XPaths. Containing the views within schema
allow me to create multiple views for any type/element with
encountering naming clashes.
>
> The views are created by parsing the declaration of the request and
response messages. A request message results in a procedure with
scalar inputs that produces and XML result. A response message
results in a procedure with XML in and scalar results. The procedures
are not yet accounting for child elements for messages with hierarchy
and multiplicity.
>
> Does this make sense, or did you have a different/better vision for
how a user would model around the new language features? As it stands
right now, I have been unable to create a procedure that executes a
service with this structure. Could be my limited abilities with SQL,
or that I've missed some limitation around our use of the XML type.
I've tried passing the requests to the physical procedure and
responses from the physical procedure using nested selects, and tried
holding them in variables to pass them, without success. I typically
end up with a validation error because I'm using a clob as a
criteria.
>
> I appreciate any and all feedback.
>
> ~jd