The image shows a device monitoring solution hosted in an OCI region and how admin users will access the solution for both business and administration or operations purpose.

As soon as the data is generated at device, the client application running on device will access the OCI Streaming on an endpoint exposed via API Gateway. These endpoints will be protected by a high end web security service – WAF – stands for Web Application Firewall. This service will make sure the frontend security is by default applicable to the application. The same streaming endpoint is connected from a Service Connector Hub, which will keep monitoring the stream and as soon as there is a new data produced by the device, it will consume the data, and trigger OCI Functions for further processing of the data.

OCI Functions will take the consumed data and start data processing. There will be scenarios where multiple records will be consumed in single consume call depending on the input traffic, and the function will be capable of taking care of all the records separately. For each record, the function will perform the following tasks:

1. Clean the record data and gather the required parameters from it.
2. Create an API Request call for the ML model hosted on an endpoint. The input for this request will be the required parameters for the model to make a device failure prediction. The response of this request will be the device failure prediction (ranging from 0.00 to 10.00, where 0.00 means least chances of device failure, and 10.00 means most chances of device failure).
3. After we get the prediction, the function will add this to the input record and push it to Autonomous Data Warehouse for future reporting, and ML model continuous re-learning.
4. Based on the prediction value, OCI Functions will trigger the next task. If the prediction is for non-failure, the function will exit the run for that record as there is nothing else to do. If the prediction is for failure, the function will perform the following sub-tasks:
   1. Access the Autonomous Data Warehouse reference table for all details for the new order like order submitter and approver details, data related to device and all other stakeholders.
   2. Use OCI Generative AI to generate the order details summary.
   3. Submit the order details to Oracle E-Business Suite, or any other ERP, CRM software.
   4. Use OCI Generative AI to draft an email for stakeholder summary.
   5. Send the notification to the corresponding stakeholders to inform about the order placement.
5. Once this flow is completed, the function will mark the record as processed, and will move to the next record.

The solution consists of a self re-learning ML model, which will keep updating itself with the new data coming to the Autonomous Data Warehouse. All three tiers of the application are hosted in different subnets to make sure we have opened the correct security ports as required by the application. The data stored in the databases are pulled from another subnet to ensure proper security.

The architecture diagram also illustrates another user access flow for admin users. These are the users who are responsible for operating the device monitoring application on OCI. They will access the application resources using SSH over Site-to-Site VPN or FastConnect. This will create a secure tunnel which will connect the CPE device in the customer data center with the DRG on OCI. Using this path, the administrators will access the application resources on OCI from the data center computers. This access is required to make sure all operations job like patching, application upgrade, operating system security upgrades and other tasks are done securely and on time.