I finally got time to do a little bit of SOAP development for RT.
I started using Jesse’s SOAP server example and managed to get it
working using SOAP::Lite on the client side.
I have one question though:
i started to make WSDL files, so that a test client in C# (well M$ .NET
architecture is the ultimate test client) can be written easily. But
in this step i discovered that the server is designed to get all ticket
creation parameters as one hash array, but i’d like to define some XML
schemas (e.g. Ticket) so that i can pass a structure on the client side.
so the ‘createTicket’ function now gets something like this as an input
parameter
@[0]:
Ticket:
Queue => 'general’
Requestor => 'mla@lausch.at’
and @[1] could be any other parameter.
are there any objections to define Schemas in the WSDL file which
describe entitys such like ‘Ticket’, ‘CustomField’ and to rewrite the
server functions to accept structs instead of one big array?
I have one question though:
i started to make WSDL files, so that a test client in C# (well M$ .NET
architecture is the ultimate test client) can be written easily. But
in this step i discovered that the server is designed to get all ticket
creation parameters as one hash array, but i’d like to define some XML
schemas (e.g. Ticket) so that i can pass a structure on the client side.
so the ‘createTicket’ function now gets something like this as an input
parameter
@[0]:
Ticket:
Queue => ‘general’
Requestor => ‘mla@lausch.at’
and @[1] could be any other parameter.
are there any objections to define Schemas in the WSDL file which
describe entitys such like ‘Ticket’, ‘CustomField’ and to rewrite the
server functions to accept structs instead of one big array?
I’m somewhat of a SOAP newbie, so I apologize if I’ve gotten it wrong.
Would it be possible to see a chunk of a WSDL file for what we’re doing
now and what we “should” be doing?
Thanks,
Jesse
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
I’m somewhat of a SOAP newbie, so I apologize if I’ve gotten it wrong.
Would it be possible to see a chunk of a WSDL file for what we’re doing
now and what we “should” be doing?
Thanks,
Jesse
what i’ve done is to define a XML schema for a ticket (it’s not complete
yet, but a start)
<xsd:complexType name=“Ticket”>
xsd:sequence
<xsd:element maxOccurs=“1” minOccurs=“0” name=“id” type=“xsd:int”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Subject”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Owner”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Cc” type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“AdminCc”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Requestors”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“DependsOn”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“DependedOnBy”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“MemberOf”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Members”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Refersto”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“ReferredToBy”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Transactions”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Starts”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Started”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Due”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Resolved”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Created”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Told”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“LastUpdated”
type=“xsd:dateTime”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Creator”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“LastUpdatedBy”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Queue”
type=“xsd:string”/>
<xsd:element maxOccurs=“1” minOccurs=“0” name=“Type”
type=“xsd:string”/>
</xsd:sequence>
</xsd:complexType>
then i’m able to define the createTicketRequest message like this:
and use the same type for the response message of the getTickets()
function and as the input parameter for updateTicket()
this means that the type (or XML Schema) ‘Ticket’ can be reused for
different functions (input and output parameters). It’s also easier to
define a 'ListofTickets type.
I’m somewhat of a SOAP newbie, so I apologize if I’ve gotten it wrong.
Would it be possible to see a chunk of a WSDL file for what we’re doing
now and what we “should” be doing?
Thanks,
Jesse
what i’ve done is to define a XML schema for a ticket (it’s not complete
yet, but a start)
<xsd:complexType name=“Ticket”>
xsd:sequence
Ow. no. that was never intended to be a sequence. I’m terribly sorry
about that.
type=“xsd:string”/>
</xsd:sequence>
</xsd:complexType>
then i’m able to define the createTicketRequest message like this:
and use the same type for the response message of the getTickets()
function and as the input parameter for updateTicket()
nod Ok. That’s much more what I intended. I’ve attached a start at a
WSDL file I had a while ago, just for trying to think things through.
Though I’ll note that the WSDL designer I used also seemed to have a bit
of a mind of its own.
this means that the type (or XML Schema) ‘Ticket’ can be reused for
different functions (input and output parameters). It’s also easier to
define a 'ListofTickets type.
rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
rt3.0.wsdl (3.94 KB)
I’m somewhat of a SOAP newbie, so I apologize if I’ve gotten it wrong.
Would it be possible to see a chunk of a WSDL file for what we’re doing
now and what we “should” be doing?
Thanks,
Jesse
what i’ve done is to define a XML schema for a ticket (it’s not complete
yet, but a start)
<xsd:complexType name=“Ticket”>
xsd:sequence
Ow. no. that was never intended to be a sequence. I’m terribly sorry
about that.
sequemnce is okay. that’s the wsdl or xml-schema way to define
structures.
type=“xsd:string”/>
</xsd:sequence>
</xsd:complexType>
then i’m able to define the createTicketRequest message like this:
and use the same type for the response message of the getTickets()
function and as the input parameter for updateTicket()
nod Ok. That’s much more what I intended. I’ve attached a start at a
WSDL file I had a while ago, just for trying to think things through.
Though I’ll note that the WSDL designer I used also seemed to have a bit
of a mind of its own.
ok. i’l use the snippet you provided as a start and follow your naming
conventions.
since i’m not good in perl, the implementation in the server will be
subject to corrections 
depending on my speed to get used to M$ Visual.NET, i’ll provide the C#
source for a server test suite at the end of the following week. also
some Python client code will come into existence (i’m more interested in
a Python client, but the .NET client is needed for interop tests).
Ow. no. that was never intended to be a sequence. I’m terribly sorry
about that.
sequemnce is okay. that’s the wsdl or xml-schema way to define
structures.
Ah. Sorry. Like I said, I’m somewhat of a SOAP newbie.
nod Ok. That’s much more what I intended. I’ve attached a start at a
WSDL file I had a while ago, just for trying to think things through.
Though I’ll note that the WSDL designer I used also seemed to have a bit
of a mind of its own.
ok. i’l use the snippet you provided as a start and follow your naming
conventions.
Actually, the bits I really care about are the property naming
conventions, and those need to stay the same as they are in core RT for
reasons of not having to do a lot of annoying data conversion. Method
names and data structure names, I’d rather follow standard SOAP
convetions for.
since i’m not good in perl, the implementation in the server will be
subject to corrections
No worries. I’d be happy to help out there.
depending on my speed to get used to M$ Visual.NET, i’ll provide the C#
source for a server test suite at the end of the following week. also
some Python client code will come into existence (i’m more interested in
a Python client, but the .NET client is needed for interop tests).
Ooh. That’s all quite exciting. Thanks!
Best,
Jesse
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.