Hi list,
my apologies for the long mail, but I thought it best to ask all my
questions in one go ;-)
I've been working on integrating OTRS with a java application via
SOAP. After a few experiments with the included SOAP::Lite interface,
I've had to abandon using rpc.pl as autodispatch does not result in
"rigorously" formed and typed SOAP messages, something that's
essential if I'm going to use apache AXIS (for example) as the
client. I've got some proof of concept code and WSDL that I want
eventually to package, but I could use some advice.
The modules aren't really core and they aren't really frontend (it's
HTTP, but you wouldn't use them via a web browser and they probably
don't require localization). I've put them in Kernel::System for now,
does that sound about right? I did think about a new structure (say
Kernel::System::WebService) but I'm not sure of the implications.
I'm initially interested in Ticket and Article objects. From those
objects what are the minimum set of fields that are required to
create a valid object? I need these so that I may create schema types
for ticket and article with optional elements that may be used in a
short form for creating those objects, but in a longer form for
retrieving them. For example can I create a ticket with QueueID _or_
Queue and later retrieve it with both QueueID _and_ Queue populated?
Are there definitive docs out there on this that I've missed? I have
the developer docs (very nice BTW, and a _big_ help ) and the ITSM
database docs from the website already. Oh yeah, and I _can_ read the
code ;-)
Finally, does this broadly sound like the correct approach? I'm
somewhat concerned about causing problems down the line by
encapsulating a few methods such as TicketGet and TicketCreate in
other objects, but it seems to be the most obvious way of adding this
capability without unsustainable messing around with the OTRS core.
The purpose of this is to start integrating OTRS::ITSM with OpenNMS
(they seem to complement each other nicely). If I can get them to
interoperate in this way, there are a lot of very cool possibilities.
I could, of course, make the interface using SMTP, but I think that
is rather a dead-end.
Cheers .... Jonathan.
(and thanks, if you've read this far)
_______________________________________________
OTRS mailing list: dev - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/dev
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
