otobo.psgi vs cgi-bin

[OrionExplorer]

Hello!

I have a question about possible migration paths for our modules.

With OTRS, we used to create custom .pl files in the $HOME/bin/cgi-bin/ directory. Also, a custom interfaces were provided in Kernel/System/Web/.

Now, with OTOBO in Docker and release of 10.1 version, the PSGI is used all the way, so we cannot simply use these .pl scripts anymore.

All definitions for index.pl, customer.pl are placed in the otobo.psgi.

So my question is: what is your suggestion to define and mount custom applications?

[bschmalhofer]

Hello Marcin,

it is very interesting to see how much users have adapted OTRS. Regarding your question I can think of several options:

The recommended solution

Create a customized my_otobo.psgi where there are additional mountpoints for the custom pathes. This means that you need custom PSGI application. For that there are at least two options.

You need adapt your Interface modules so that they work with PSGI. This might be a bit of work. The major things are that you need is the method Content() that emits the content without headers. The headers are stored in the global Kernel::System::Web::Response object. See also https://github.com/bschmalhofer/otobo-ideas#psgi-stumbling-blocks .

The maybe best solution

Take a look at your interface module and determine the easiest way to turn it into a PSGI app. This might be more appropriate, because for the standard interface I had to jump through some hoops to make it work without too many internal changes.

The workaround

Wrap your existing scripts from cgi-bin and wrap them with CGI::Emulate::PSGI. This is the approach from OTOBO 10.0.

The future

It would also be possible to implement support for custom interfaces, where the interfaces are registered in the SysConfig. This would allow to add custom interfaces via OTOBO packages. But this idea hasn't really been thought through and no implementation is yet planned.

Best regards,
Bernhard

[OrionExplorer]

Hello Bernhard,

thank you for your reply. I'd like to discuss the options you presented:

The recommended solution

Create a customized my_otobo.psgi where there are additional mountpoints for the custom pathes. This means that you need custom PSGI application.

First of all - forgive me my lack of knowledge about PSGI. Creating custom .psgi sounds great, but does this method allow me to use otobo.psgi and my custom .psgi apps simultaneously?
As I mentioned in my original question, we have quite a few separate modules that make use of the custom scripts from cgi-bin directory. And sometimes we need to install 3 or 5 or 7 of them, it depends from customer. Is that really possible to achieve with custom PSGI apps?

The maybe best solution

Take a look at your interface module and determine the easiest way to turn it into a PSGI app. This might be more appropriate, because for the standard interface I had to jump through some hoops to make it work without too many internal changes.

Unfortunately right now I cannot go this way, because we have customers stuck in OTRS. Our modules architecture is designed for both OTRS and OTOBO, based on a single codebase. I am afraid that solution would break that rule.

The workaround

Wrap your existing scripts from cgi-bin and wrap them with CGI::Emulate::PSGI. This is the approach from OTOBO 10.0.

I see how it's used here, but where do you think I should place the code to maintain backward compatibility with non-docker-OTOBO installations and old OTRS installations?

I really would like to prevent overwriting otobo.psgi at all cost. :)

Regards,
Marcin

[OrionExplorer]

Hi Bernhard,

ok, now I understand the possibility to wrap otobo.psgi with another .psgi file. But would that work for more than one package as I mentioned in my previous message? I am not sure it would be possible to maintain.

After all, I am not really forced to use .pl scripts, these are mostly used as endpoints for unauthorized, complex requests from external applications (sadly the WebServices would not apply).

Maybe the best approach in this case is to leave them behind and move entirely to the PublicInterface? That's certainly some more effort to take, but - correct me, if I'm wrong - it would work both for legacy OTRS installations and OTOBO 10.0/10.1.

Regards,
Marcin

[bschmalhofer]

Hi Marcin,

of course it depends on your environment and how you provide the extra CGI-scripts.

In your case I can imagine that the application Plack::App::CgiBin would do the job. Maybe even Plack::App::WWW. In this case you could even use the wrapper scripts provided bin/cgi-bin/ . But note that the wrappers like bin/cgi-bin/index.pl are really just workarounds and are their use is discouraged.

Another posibiltiy is to use the object oriented interface of Plack::Builder. Scan the directory bin/cgi-bin and dynamically add the extra routes.

Yet another possibility. Mount the extra routes under http://my.host/otobo-extra , Then you can use Plack::App::CgiBin for otobo-extra and otobo,psgi for everything else. This would actually be my recommendation.

Best regards,
Bernhard

[OrionExplorer]

Hi Bernhard,

after some thinking and finding out about #1645 I need to end up with solid and backward-compatible solution for our packages.

So, I see there are lot of plans regarding OTOBO architecture in the future, but I understand that at least InterfaceAgent, InterfaceCustomer and InterfacePublic are going to stay around? :)

I'd really like to go full-PSGI, but my hands are tied due to the scale of supported OTRS installations.

After all, knowing that I am not able to reimplement everything using PSGI (damn OTRS), what's your opinion on moving everything from custom .pl scripts in cgi-bin to PublicFrontend?

Regards,
Marcin

[svenoe]

Hey Marcin,

just a quick note from my side: #1645 is a proposal of Bernhard who is generally eager to get rid of things (with good reasons, of course ;) ) - with regards to this, nothing is decided, yet, though... Especially if there is the justified wish and need from the community to keep those scripts, this is a good reason then to keep them and will be on our mind there. Currently I would expect that we keep them at least for 11.0, but we didn't have that discussion yet.

InterfaceAgent etc. for the moment will definitely stay.

Best regards, Sven

(Edit: This is not a proposal to use those scripts, just the note, that we will try to not rush things.)

[bschmalhofer]

Hi Marcin,

yes, as Sven said nothing is decided yet.

From this discussion I see that there is the need for supporting extra routes, and that not all routes can be expected to be Plack-Applications. I still envisage supporting routes like http://example.org/otobo-addons/my_otobo_addon. The addons can then be registered in the SysConfig. And the implementations can be packaged as OTOBO packages. At least three kinds of implementations should be supported:

• plain old CGI-scripts
• Perl modules that are Plack applications by themselves, including Config settings
• ,psgi files that may be combining several Plack applications

As you found #1645 you might also want to read and contribute to the discussion in #1599.