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)
Hi Jonathan, On Apr 10, 2008, at 23:16 , jonathan sartin wrote:
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.
Cool!
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.
Sounds appositely correct. :)
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 ;-)
For a ticket you need a Queue, Priority, State, Owner, Lock and User (who is creating this ticket). The first communication part (the first article) need to have TicketID, ArticleType, SenderType, From, Subject, Body, ContentType, HistoryType, HistoryComment and User (who is creating this article). I can also offer som help, so just say me or give me an example of you client code and I can add the needed stuff.
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.
Sounds very cool! :) -Martin -- ((otrs)) :: OTRS AG :: Europaring 4 :: D - 94315 Straubing Fon: +49 (0) 9421 56818 0 :: Fax: +49 (0) 9421 56818 18 http://www.otrs.com/ :: Communication with success! Address of record: Bad Homburg Local Court: Bad Homburg, HRB 10751 Tax number: 003/240/97505 Chairman: Burchard Steinbild Chief Executive Officer: André Mindermann
On 11 Apr 2008, at 23:38, Martin Edenhofer wrote:
For a ticket you need a Queue, Priority, State, Owner, Lock and User (who is creating this ticket).
The first communication part (the first article) need to have TicketID, ArticleType, SenderType, From, Subject, Body, ContentType, HistoryType, HistoryComment and User (who is creating this article).
OK, that's a good start, I can work from there.
I can also offer som help, so just say me or give me an example of you client code and I can add the needed stuff.
I will probably ask for some help, once I have a basic package down, to clean up my code and make it suitable for public consumption ;-) Cheers .... Jonathan.
participants (2)
-
jonathan sartin -
Martin Edenhofer