Our home-grown Ticket System have SOAP interface. What is the recommended architecture to integrate DataMiner with it?
Requirements:
DataMiner will receive traps and generate alarms from multiple sources. Such alarms must be correlated in DataMiner, which will interface with Ticketing System.
Ticket System will generate work order and upon work order closure will verify with DataMiner if condition has been cleared or still active. Only allowing work worder closure if condition that generated work order is no longer present.
All work order management life cycle will be handled by home-grown ticketing system.
Roger,
This is a perfect use case for DataMiner and the architecture is rather flexible. Please see below for a common approach.
- DataMiner receives trap or generates native event/alarm
- DataMiner workflow managers apply business logic
- DataMiner interfaces with the external ticketing system and triggers the creation of ticket
- When it comes to clearing the ticket, various approaches apply. Some below:
- DataMiner could send a ticket update once the clear event for the original alarm is received. This approach saves the need for the ticketing system to query DataMiner which tends to be more efficient (push vs polling)
- Ticketing system could query DataMiner for the status of the source alarm
Note that at every step of the process, DataMiner is able to perform all operations in a load-balanced fashion. However, when it comes to the interfacing with the ticketing platform, we prefer for this to support multi-threading, which means that DataMiner can perform multiple operations in parallel. If the Ticketing system doesn't support multi-threading, DataMiner would need to buffer the ticketing creation/update, which tends to be less performant.
Thanks,