AUTOMATIC WORK ORDER OPENING SYSTEM

Abstract

This invention relates to a system (1) developed to provide a real-time and event-based microservice integration between the roof fault management systems and fault or ticket management systems used in information technology and telecommunication infrastructures.

Description

1 TARIFF AUTOMATIC WORK ORDER OPENING SYSTEM Technical Area This invention addresses the fundamental fault used in information technology and telecommunications infrastructures. real-time communication between management systems and fault or ticket management systems. It relates to a system that provides an event-driven microservice integration. Previous Tech 10 In the integration of roof defect management systems and work order systems, new Periodic database polling to identify fault records This approach is used. In this structure, systems receive data at specific time intervals. It checks the database to see if there are any new fault reports; this situation is 15 This leads to unnecessary database queries, delays, and increased system load. However, the consumption rate of incoming alarms and external ticketing The fact that there is a direct dependence between the processing speeds of the systems, working sufficiently independently and loosely coupled It hinders the processing of alarms, especially in situations where alarm volume increases. Delays and bottlenecks can occur in the process, affecting the processing capacity of external systems. This can directly affect the operating speed of the resource systems. Therefore, the roof fault used in information technology and telecommunication infrastructures Real-time and 25-hour communication between management systems and fault or ticket management systems. We need a system that provides an event-driven microservice integration. It seems that it was heard. 2 United States patent number US12625863, which falls under the prior art. in the document, from database-centric operating systems for persistent workflows It is mentioned that the invention in question is built upon a transactional data store. The operating system platform is described. The platform provides workflow status information. 5 configured for storage and incorporating operating system services It includes a transactional data store. A workflow engine is a specific component of the workflow. with detailed explanations from decorators who specify the infrastructure requirements of the section It executes a defined workflow. The platform also supports historical versions of the data. an origin database for storing periodic tasks and event-driven operations. It includes a timer to manage the execution of tasks. 10 Brief Description of the Invention The purpose of this invention is to utilize information technology and telecommunications infrastructures. There is a real difference of 15 between roof fault management systems and fault or ticket management systems. to provide a microservice integration that operates in a time-based and event-based manner It is about implementing a developed system. Detailed Description of the Invention The "Automatic Work Order Opening System" developed to achieve the purpose of this invention is attached. This is shown in the figure; Figure 1 shows a schematic view of the system that is the subject of the invention. The parts shown in the figure are individually numbered, and the corresponding numbers correspond to these numbers. It is given below. 3 1. System 2. Database 3. Server Fault management systems used in information technology and telecommunication infrastructures 5 Real-time and event tracking between systems and fault or ticket management systems. an invention developed to provide a microservice integration that operates based on a microservice model subject system (1); -keeping alarms as a task queue, tickets created with alarms 10 Ensuring that ticket groups are matched with each other and that redirects are stored at least one database structured to (2) and -Receiving alarms from the roof fault management platform, forwarding incoming alarms to Apache High speed and real-time via message queuing technology. the consumption, decoding of data in Euro data format, and only the necessary fields. normalization is performed and a task object is generated from the database (3) 15 the withdrawal of tasks, the external ticketing platform and roof by running a state machine the platform enables data exchange via API, ticket creation, running association or deactivation commands, cleaning up outdated records the resumption of tasks that have become stuck due to crashes or interruptions. synchronization is performed, external platform dependencies are isolated 20 this involves adding a new database or ticketing platform to the workflow. Factory and ABC designs do not require modification of the main code in these situations. at least one server configured to enable the use of patterns (3) It includes. The database (2) in the system (1) which is the subject of the invention, any communication protocol to communicate with the server (3) and exchange data using It is being structured. 4 The server (3) in the system (1) which is the subject of the invention, uses any communication protocol to communicate with the database (2) and exchange data using It is configured. The server (3) is configured with alarm sources with different speeds. Ticketing application programming interface (API) between Producer, Consumer and 5 Establishing a loosely coupled connection using the outbox pattern, Alarms are instantly consumed and resolved from the message queue platform without delay. writing to the database (2), tasks written to the database (2) capacity ensuring safe retrieval and processing of the ThreadPoolExecutor and lock Resource management using mechanisms, alarm 10 even if external API slows down ensuring that consumption does not stop or collapse, and that the task is completed successfully if the process is successful. termination and exponential rollback if a network outage or temporary API error occurs. the algorithm postpones the task to the next available time and tries again. It is structured to provide the server (3), state machine algorithmic architecture. with the tasks, the status of the process itself, the status on the ticketing platform, and the alarm 15 the status at the source and the monitoring of the same task on three different axes. To ensure that double ticketing is absolutely prevented in cases where it enters the flow. It is structured accordingly. The server (3) uses a race status resolution algorithm and the ticket is not yet available. The flow throws an error when an association request for the same alarm comes in before it's created. preventing a crash and performing very short, intelligent waits on the first attempt 20 The flow with its unique asynchronous timing logic that allows the main ticket to be generated. It is configured to ensure its advancement. The server (3) is overloaded or the driver With psychological protection, multiple threads can be loaded into the database (2) at the same time. preventing the connection pool from becoming congested and controlling traffic at every stage of the process. 25 to enable the assignment of a custom stepped sleep timer to the particle It is configured. The server (3) is configured until an alarm received reaches the ticketing platform. If it corrects itself within that short period, it's an unnecessary ticket to the destination. proactive detection of the opening and automatic removal of the task from the workflow. It is structured to ensure that it is reduced through a decision-making mechanism. Industrial Applicability Thanks to the system (1) that is the subject of the invention, information technologies and telecommunications fault management systems and ticket management systems used in their infrastructures a microservice integration that operates in real-time and event-based between systems is provided. Around these basic concepts, the subject of the invention is "Automatic Work Order Opening System (1)". It is possible to develop a wide variety of related applications, and the invention described herein It cannot be limited to examples; it is essentially as stated in the requests.

Claims

6 REQUESTS 1. The roof fault used in information technology and telecommunication infrastructures. There is a real connection between management systems and fault or ticket management systems.

5. It provides a microservice integration that operates in a time-based and event-based manner. -keeping alarms as a task queue, tickets created with alarms to enable matching and storing directions containing at least one structured database (2) and -Receiving alarms from the roof fault management platform, and managing incoming alarms. Apache message queuing technology provides high-speed, real-time 10 consumed as is, decoded data in Euro data format, only normalizing the necessary fields to generate a task object, (3) tasks are retrieved from the database by running a state machine externally. Exchanging data via API with the ticketing platform and the umbrella platform. the execution of ticket creation, association or closing commands 15 operation, cleaning up outdated records, crash or interruption resynchronization of tasks that get stuck in situations like these to implement, isolate external platform dependencies, a new main instances where a database or ticketing platform will be added to the flow Factory and ABC design patterns, which do not require code modification, are 20 with at least one server (3) configured to enable its use a characterized system (1).

2. To communicate with the server (3) using any communication protocol and database (2) configured to carry out data exchange and 25 A system like the one in Claim 1, characterized (1). 7 3. Communicate with the database (2) using any communication protocol. and characterized by the server (3) configured to carry out data exchange. A system like the one in Request 1 or 2 (1).

4. Ticketing application with alarm sources that have different speeds 5 Programming interface (API) pattern: Producer, Consumer and Outbox using a loosely coupled connection to establish a message queue Alarms are instantly consumed and resolved from the platform without delay, providing data. writing to the base (2), tasks written to the database (2) capacity ensuring safe retrieval and processing of ThreadPoolExecutor and lock 10 managing resources using these mechanisms, even if the external API slows down. The alarm consumption should not stop or crash, the process should be successful. If completed, the task will be terminated and there will be a network outage or a temporary API failure. If an error occurs, the exponential fallback algorithm will be used to move the task to the next available slot. Server 15 configured to allow for a retrial after a time delay. (3) like any of the above-mentioned claims characterized by system (1).

5. State machine algorithmic architecture: tasks and the state of the process itself. the status on the ticketing platform and the status at the source of the alarm 20 tracking on three different axes and the same task entering the workflow to ensure that the issuance of double tickets is absolutely prevented in these situations any of the above requests characterized by the configured server (3) a system like one of them (1).

6. Race status resolution algorithm for the same alarm even before the ticket is created. Preventing the flow from crashing and giving an error when an association request arrives. and in the first attempt, very short smart waits are made and the main ticket is generated. the advancement of the flow with a unique asynchronous timing logic that provides opportunities 8 the above characterized by the server (3) configured to provide a system like any of the requests (1).

7. Data handling of multiple threads with overload or swarm psychology protection. 5 and phased sleep specific to each workpiece using traffic control method server configured to enable the assignment of timer (3) a system like any of the above characterized demands (1).

8. The short time it takes for an alarm to reach the ticketing platform. If it corrects itself, proactively opening unnecessary tickets to the target detection and automatic decision-making mechanism from the task flow characterized by the server (3) configured to ensure its downgrade a system like any of the above requests (1).

Images