System of standardized api interpretation for inter application communication

Abstract

Managed Inter Application Communications and Relationships (MIAC) is a system for business process automation that uses recognised standard application programming interfaces (API), data base schema mapping and raw data to collect, translate and transfer data to facilitate processes that incorporate data transfers, communications, event creations, alerts and physical inputs to build an end-to-end work flow where all actions and communications are recorded for audit and automated feedback response cycles. The system allows for an incremental build of a matrix computer network where all connected systems are separated but communicate in an intelligent rule and workflow driven process, controlled and influenced by the human workforce.

Description

FIELD OF THE INVENTION[0001]The present invention relates to a communications matrix network architecture. The system connects and combines communications between software as a service (SaaS) web services, bespoke on-site software services (IT platforms), operational technology services (OT systems), web connected sensors, and personnel communications including mobile devices (the systems). It establishes relationships between all connected services and personnel in a mutual and hierarchical project and task based architecture, Managed Inter Application Communications (MIAC). The system retains the connected systems integrity and individuality whilst still allowing them to integrate and communicate on a central platform.BACKGROUND[0002]Discussion of Different Patents Similar to but Different to this Patent:Project Management Database and Method of Managing Project Related Information US 20110231391 A1[0003]This patent is not a task and project based software that includes a workforc...

AI Technical Summary

Benefits of technology

The patent describes a system that records and sends notifications about tasks or processes. The system allows quick and accurate decision-making based on the raw data related to the task. It also triggers alerts when a process fails and allows the assigned personnel to communicate directly with higher-level management. Overall, this system improves response times and makes it easier for people to manage and mitigate problems in real-time.

Problems solved by technology

Often the systems connected with an ESB use a plugin and external notification system that does not handle workflow process.

Some of the systems are connected to each other via API to generate a logical or known next-step action, but where connectivity is not available, cost effective or difficult for the business to do independently, manual data transfer is necessary.

This increases the frequency of human intervention and error into the process.

These manual transfers account for a large proportion of process failures and interruptions resulting in lost productivity and profit.

Systems which have the inability to connect in a reliable and stable manner may be viewed by their clients as unusable and or render the product unsaleable.

The current high cost of system integration is a key reason for organisations not integrating systems when it is more cost-effective to maintain manual data transfer in spite of increased risk of human error and productivity foregone.

As ‘the systems’ are written in different computer languages, it is a significant challenge to integrate IT, OT, MD (mobile device) and HR systems to act and perform in vastly different ways.

The volume and complexity of code writing work involved in connecting systems within a Bus is extensive and usually requires a 3rd party provider to the ESB provider to complete the service.

Some open source (OS) ESB providers provide a cheaper entry point and more functional user interface (UI) that allows clients to build their own ESB, but the drawback is a more limited functionality and choice.

These ESB's do not fit the requirements of larger organisations with complex processes and systems.

Personnel notifications and communications is a plug-in application approach to the involvement of personnel in a business process and does not integrate a defined workflow into a process that is easily accessible.

A common problem with a standard API system is that a person wishing to integrate that application with other applications or services must first learn the API structure including calls and functions of all the systems to be integrated before building the integrated system.

This problem is complicated further by the fact that, often, integration is being done across multiple applications and services from different vendors, where each individual API may have its own unique call and function description and operation set.

To date there has been no standardized API interpretation service to normalize the language functionality and naming of calls and functions across any combination of applications and or services, across any and all vendors.

This service, while popular, does not fulfil the needs of a typical professional system integrator.

This architecture does not solve the problem previously outlined, in that to achieve a truly powerful and flexible system integration, the most complex and specific API calls and functions available from an application must be available to the integrated system in order to achieve the maximum benefit from the integration with other applications or services.

This approach severely limits the power and functionality of a professional, integrated, multi-application and service system.

Images