Monitoring

HTTP Event Transport

In our example, we will configure an HTTP Event Transport from anynode to Microsoft Teams using Microsoft Azure Logic App. This chapter describes the setup of HTTP Event Transport in anynode with the Event Transport Assistant.

This setup helps streamline incident response and maintain high availability for telephony systems.

The HTTP Event Transport Configuration acts as a bridge between anynode's event system and the HTTP server.

In the upper menu, navigate to Extras and Event Transport.

anynode frontend main view with extras menu and event transport.

You will get the list of event transport objects.

Click on Add.

anynode with list of event transport objects and add function.

At Severity filter, configure which events should be transported depending on their severity.

Select the category of events that should be sent. By default, all categories are activated.

The options are:

Error

Warning

Information

Open the lock if you want to make some changes.

In our example, the failure of the provider node is classified as an error, so we restrict notifications to error events only.

However, since we only want to receive an email in case of a provider failure and not for other node failures, we also uncheck the Error option. In the next step, we will set up a specific event filter.

Open the lock and deselect Error, Warning and Information.

Click Next.

anynode event transport assistant with severity filter.

At Included events you can configure which events should be transported regardless of their severity.

The filter function in the upper section provides a convenient and efficient way to narrow down and locate desired events quickly.

In our example, we want to receive an error message via email when the provider node is out of service. (ID 900)

Select ID 900 or your desired IDs.

Click on Next.

anynode event transport assistant with included events.

To limit the email notification to only the "Provider" node when it fails, follow these steps:

Select the ID 900 event.

At the bottom right, you'll find the Edit Condition option.

Adjust the Condition:

In the Event filter, you can define the specific conditions under which the email will be sent.

Choose the default value: any of the conditions below must be met

Click on the +

Choose Node Name as Parameter.

Choose is equal to as comparison operator.

Make sure to adjust the condition so it only applies when the "Provider" node fails. Choose your provider node as comparison value.

Click on Ok.

This way, you can target the notifications specifically to the "Provider" node, without receiving emails for failures on other nodes.

anynode event transport assistant with included events and event filter.

At Excluded events, you can configure which events should not be transported.

In our example, we don't want to exclude events.

Click on Next.

anynode event transport assistant with excluded events.

At Transport type, select a transport protocol.

Choose HTTP and as Profile REST.

anynode event transport assistant with transport protocol selection.

The Network controller manages how and where event data is sent. he Use a fixed address option ensures that anynode will always utilize the specified IP address. This is ideal for static network configurations that are not expected to change. However, this setting is not suitable if your network adapter is configured using DHCP, IPv6 autoconfiguration, or any other automatic process.

The Use an interface's address option automatically uses the IP address assigned to a network adapter. Changes to the assigned address are tracked, and the IP address is updated accordingly. This setting is recommended for dynamic network configurations where changes are expected, such as setups using DHCP, IPv6 autoconfiguration, or similar processes. Since network interfaces often have both IPv4 and IPv6 addresses, selecting the appropriate Internet Protocol version is mandatory.

The Advanced configuration option allows anynode to operate in roaming mode across multiple or changing networks. It also supports scenarios where a single configuration applies to multiple similarly configured anynode instances, such as in clustering or high availability setups.

In our example, we will use the second option with our network card: Use an interface's address.

Click Next.

anynode event transport assistant with network controller settings.

Parameter options in the Event Transport Assistant provide the customization and flexibility needed to meet the technical requirements of HTTP-based event transport. They ensure compatibility with external systems, secure transmission, and the ability to dynamically adjust event data for various scenarios.

The HTTP parameter mode specifies if the event information is sent as QUERY parameter in the request URI, in the HTTP BODY or as JSON for REST requests.

The HTTP Content-Type is set in the HTTP header. The parameter is only used if the parameter mode is set to BODY or REST.

In most cases, you can use the default values here.

Click Next.

anynode event transport assistant with transport protocol selection.

At Request options, the Request URI specifies the exact endpoint on the receiving server or API that will process the event. Without it, anynode would not know:

• Which server to contact.

• Which application or service on the server should handle the event.

In our example, we use the HTTP URL created in Microsoft Azure Logic App in the previous chapter. The full URL must be specified in the configuration. The host name and port information are automatically separated from the URL.

The Request type may be set to POST, PUT or GET. The default is POST.

When to Use Each Request Type:

• Use POST: When sending new events or data to a system that processes and stores them.

• Use PUT: When updating existing data or replacing it entirely on the destination system.

• Use GET: When you only need to trigger an action or retrieve data without sending much detail.

In our example, we use POST. Timeout is the maximum duration in seconds for sending the request and waiting for the response.

Click Next to continue.

anynode event transport assistant with options for the HTTP request.

anynode will try to retrieve the peer certificate automatically.

Check the State for: Certificate successfully autodetected.

Click Next.

anynode event transport assistant with trusted certificates required to validate the HTTPS connection.

If the Microsoft Logic App is set up with the "When an HTTP request is received" trigger and configured to accept anonymous HTTP requests, then you don’t need OAuth. The URL provided by the Logic App already includes a security token (in the query string), which acts as an authorization mechanism. For secure and robust workflows, it's a good practice to configure an OAuth client whenever possible. However, for simpler use cases, relying on the built-in Logic App URL token may suffice.

Therefore, we skip this step.

Click Next.

anynode event transport assistant with OAuth client configuration.

If the HTTP trigger in the Logic App does not enforce authentication (e.g., no Basic Authentication or OAuth), it will accept requests from any source that knows the endpoint URL. Azure Logic Apps generate long and complex trigger URLs. You can add an authentication layer to prevent unauthorized access. In our example, we do not enforce authentication.

Click Next.

anynode event transport assistant with credentials for your client.

Select the frontend URL to include it in your message. Within the template, keywords can be used to embed event-specific information. Valid keywords are:

• dateTime keyword for referencing date and time in the template.

• severity keyword for referencing the severity of the event.

• informational keyword for inserting the severity warning.

• error keyword for inserting the severity error.

• id keyword for referencing the event identifier.

• message keyword for referencing the message text of the event.

• param1 keyword for referencing the first event parameter

• param2 keyword for referencing the second parameter.

• param3 keyword for referencing the third event parameter.

• param4 keyword for referencing the fourth event parameter.

• versionkeyword for referencing the anynode version.

• systemId keyword for referencing the system identifier.

• systemName keyword for referencing the system name.

• frontendLink keyword for referencing the frontend link.

Click Next.

anynode event transport assistant with message template configuration.

The built-in Test function in the assistant allows you to quickly test email sending with the configured settings. This enables you to verify the functionality of your inputs during the configuration process. Select a desired Event ID and, if necessary, specify the Node name.

In our example, we want to send a test message when the provider node fails.

Click the Test button.

The status should then display "Success!".

Click Next.

anynode event transport assistant with integrated test function.

You should get this message via Microsoft Teams:

anynode event notification message via Microsoft Teams chat message.

Enter a meaningful name that helps you identify this event transport.

In our example, we change the suggested name to Event Transport HTTP.

Click Finish.

anynode event transport assistant with name setting that helps you identify this event transport.

You will get an overview of your configured event transport.

Click Edit for changes or Ok to close.

anynode event transport with list of event transport objects.

With your Azure Logic App and anynode HTTP Event Transport seamlessly integrated, you're now equipped to efficiently monitor anynode via Microsoft Teams.