Aggregate multiple OTRS

Moderator: crythias

Locked
nmneves
Znuny newbie
Posts: 2
Joined: 01 Jul 2010, 13:35
Znuny Version: 2.4

Aggregate multiple OTRS

Post by nmneves »

Hello.

I would like to know if anyone already had this scenario.

We would like to have an OTRS installation in each cliente, with its own ID, and let the users access locally. So, in case there is a network problem, local users can still access it.

At the central office, we would also have an OTRS installation, but would like to be able to see the tickets from every client.

Is there some synchronization available, or some aggregation of multiple OTRS for a central technical team?

Thank you,

Nuno
kool_kid
Znuny newbie
Posts: 86
Joined: 13 Feb 2011, 13:51
Znuny Version: 3

Re: Aggregate multiple OTRS

Post by kool_kid »

Logically speaking, otrs works on Database. If you can sync/replicate databases on different locations then this is doable.

All you need to do is install otrs and link it to the database, one database for all locations.
OTRS 3.1.10
ferrosti
Znuny superhero
Posts: 723
Joined: 10 Oct 2007, 14:30
Znuny Version: 3.0
Location: Hamburg, Germany

Re: Aggregate multiple OTRS

Post by ferrosti »

Lining all systems to one database does not make any sense, since a network problem would result in data loss or malfunction of its respective local OTRS system. Additionally each OTRS got its own system id and therefor creates its own TicketNumbers, as well as TicketIDs. While TicketNumbers are unique throughout the systems (in case sys-id is encoded), TicketIDs are not. So a simple DB sync will result in a huge mess.

I got the same idea for some other reason. We have lots of mandants in several countries, as well as subsidiaries, in-house OTRSs, etc. It would be nice to have these mandants physically divided, but transparently connected. E.g. let agents from site a move a ticket to a queue of site b which is running another system.

ATM I am thinking about having a master that generates TicketNumbers and replicates them in packages of e.g 10000 to each system. All systems need to accept tickets with these known system ids.
The main problem at this point is moving the whole ticket from one system to the other, since this is not about a single forwarded article. And the next thing is whether the agents of site a still need access to this ticket after it has been moved.
openSuSE on ESX
IT-Helpdesk: OTRS 3.0
Customer Service: OTRS 3.0 (upgraded from 2.3)
Customer Service (subsidiary): OTRS 3.0
+additional test and development systems
Locked