A customized openresty server used as a REST-enablement platform for existing app?

2009/5/13 云帆江 <jyf...@gmail.com> 我喜欢triger api这个概念Glad you like it :) &#x75...

brillobaby · 2009-05-21T00:32:23+00:00

2009/5/13 云帆江 <jyf...@gmail.com> 我喜欢triger api这个概念Glad you like it :) &#x75...

A customized openresty server used as a REST-enablement platform for existing app?

brillobaby

Hi There -

We utilize OTRS for customer care in our organization.  This is an
open source  trouble-ticket web-app written in perl with a back-end
mysql database. www.otrs.org

We would like to expose reading and writing certain otrs objects to
other inhouse web applications via REST.  I'm wondering if using
OpenRESTY for this is a good or even possible option for this task.

 The two concepts I have are:

(A) database exposure: Can openResty substitute mysql for postgres?

(B) alternative backend:  OTRS has a nice set of PERL apis so would it
be possible to customize openResty to substitute these instead of
using the postgres DBMS ?

We are not perl experts by any means so I apologise if this is a dumb
idea.

thanks,
Lisa

agentzh

On Thu, May 21, 2009 at 12:32 AM, Lisa <bril...@gmail.com> wrote:

We would like to expose reading and writing certain otrs objects to
other inhouse web applications via REST. I'm wondering if using
OpenRESTY for this is a good or even possible option for this task.

I believe it's possible and maybe a good choice ;)

The two concepts I have are:

(A) database exposure: Can openResty substitute mysql for postgres?

This alternative does not work at the moment. mysql backend is currrently missing but has been in our TODO list for quite a while :P

(B) alternative backend: OTRS has a nice set of PERL apis so would it
be possible to customize openResty to substitute these instead of
using the postgres DBMS ?

OpenResty has been supporting custom handlers for months now although documentation is severely lacking :)

I think you can define your own handler class by subclassing OpenResty::Handler::Base and define your own processing hooks for various REST interfaces utilizing OTRS's Perl API.

There has been an Empty backend in OpenResty which turns down database storage (see OpenResty::Backend::Empty). If you don't care about OpenResty's Role/Model/View/Feed/etc APIs, you can tell OpenResty to load your own OTRS handler only in your site_openresty.conf file:

    [frontend]
    ...
    handlers=OTRS

    [backend]
    type=Empty
    ...

I've just coded up a toy Shell handler to serve as a minimal example (approximately 100 lines of code):

    http://github.com/agentzh/openresty/blob/master/lib/OpenResty/Handler/Shell.pm

Please see its POD documentation at the end of the file. Test cases for this handler could be found in the following .t file:

   http://github.com/agentzh/openresty/blob/master/t/56-shell.t

All tests are passing on my machine ;)

We are not perl experts by any means so I apologise if this is a dumb
idea.

This is a very important question we've been trying to answer well ;)

Thanks!
-agentzh

agentzh

On Thu, May 21, 2009 at 12:19 PM, agentzh <age...@gmail.com> wrote:

I think you can define your own handler class by subclassing OpenResty::Handler::Base and define your own processing hooks for various REST interfaces utilizing OTRS's Perl API.

Forgot to mention that while developing custom handler, it's recommended to run perl -c Foo.pm yourself to check syntax error, or OpenResty would simply give you a misleading error like this:

{"error":"Handler for the \"shell\" category not found.","success":0}

I'll look into this and fix it in a future release :)

Test cases for this handler could be found in the following .t file:

http://github.com/agentzh/openresty/blob/master/t/56-shell.t

All tests are passing on my machine ;)

To run this test script on your own machine, set these in your site_openresty.conf:

[frontend]
handlers=Shell

[backend]
type=Empty

and run the test like this:

USER=agentz prove -Ilib t/56-shell.t

Hope this helps,
-agentzh

agentzh

On Thu, May 21, 2009 at 12:25 PM, agentzh <age...@gmail.com> wrote:

Forgot to mention that while developing custom handler, it's recommended to run perl -c Foo.pm yourself to check syntax error, or OpenResty would simply give you a misleading error like this:

{"error":"Handler for the \"shell\" category not found.","success":0}

I'll look into this and fix it in a future release :)

Already fixed in the new CPAN release 0.5.11 :)

and run the test like this:

USER=agentz prove -Ilib t/56-shell.t

The USER environment variable is no longer used in 0.5.11 :)

Have fun,
-agentzh

brillobaby

Wow thank you very much for the quick and helpful response.  I will
cross-post the customHandler examples to the OTRS dev group and keep
you appraised of our progress.

On May 21, 3:29 am, agentzh <agen...@gmail.com> wrote:
> On Thu, May 21, 2009 at 12:25 PM, agentzh <agen...@gmail.com> wrote:
> > Forgot to mention that while developing custom handler, it's recommended to
> > run perl -c Foo.pm yourself to check syntax error, or OpenResty would simply
> > give you a misleading error like this:
>
> >     {"error":"Handler for the \"shell\" category not found.","success":0}
>
> > I'll look into this and fix it in a future release :)
>
> Already fixed in the new CPAN release 0.5.11 :)
>
> > and run the test like this:
>
> >    USER=agentz prove -Ilib t/56-shell.t
>
> The USER environment variable is no longer used in 0.5.11 :)
>
> Have fun,
> -agentzh

agentzh

On Fri, May 22, 2009 at 10:12 AM, Lisa <bril...@gmail.com> wrote:

Wow thank you very much for the quick and helpful response.

You're very welcome :)

I will
cross-post the customHandler examples to the OTRS dev group and keep
you appraised of our progress.

Yay!

Cheers,
-agentzh