I would love to do something with DBD::Multi but this doesn't seem welll
supported by Linux distributions.
In the end, I'm considering using the CustomerUserImportExport and
CustomerCompanyImportExport plugin from OPAR
(http://opar.perl-services.de/bin/index.cgi/package/author/CAPEIT).
Br,
Cyrille
Le 25/04/2013 21:26, Michiel Beijen a écrit :
Hi Cyrille,
On Thu, Apr 25, 2013 at 2:29 PM, Cyrille Bollu <cyrille.bo...@belnet.be> wrote:
Of course, we don't use a MySQL server for our Customer data; That would
have been too easy... ;-) So the proxy solution doesn't apply. (We use a
MS-SQL non-clustered backend btw)
I'm sorry, I don't know why I assumed MySQL.
Based on this understanding, I think I'll go for a scripted import of
CustomerUser and CustomerCompany data.
This is of course always an option, and would probably be easiest.
Customize OTRS so that it accepts a 2nd DSN to try to connect to in case it
fails to connect to the primary one at application startup => Restarting the
application would still be needed in case of backend failure.
Yeah this could be possible.
Add DBD::Multiplex support to OTRS => Doesn't seem well supported (no
package in Ubuntu)
Maybe the better module to use is DBIx::HA
https://metacpan.org/module/DBIx::HA or DBD::Multi
https://metacpan.org/module/DBD::Multi
And one other option might be, that if the app you pull data from is
HA, to create a customer backend for this specific app that uses its
API, instead of raw SQL.
--
Michiel
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
