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
Aggregate multiple OTRS
Moderator: crythias
Re: Aggregate multiple OTRS
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.
All you need to do is install otrs and link it to the database, one database for all locations.
OTRS 3.1.10
-
- Znuny superhero
- Posts: 723
- Joined: 10 Oct 2007, 14:30
- Znuny Version: 3.0
- Location: Hamburg, Germany
Re: Aggregate multiple OTRS
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.
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
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