< !!! INTERNAL USE ONLY !!! >
Not for distribution directly to end user
Overview
This article documents the observed integration architecture between the on-premises Alertus platform and the Rave Mobile Safety service. It is intended to help technical staff understand message flow, configuration dependencies, validated findings, and the next troubleshooting boundary without treating unverified assumptions as established fact.
CCBC uses Alertus and Rave as interconnected emergency-notification platforms. Alertus is hosted on a Windows server on the college network and is administered through a web interface. Rave provides the complementary notification service. The integration uses Common Alerting Protocol (CAP) configuration objects, listeners, profiles, templates, rules, recipients, and device targets to move an alert between the platforms and determine how it is delivered.
Audience
ITS Staff
Process
Architecture at a Glance
The practical message path is bidirectional. A Rave-originated alert may be sent to Alertus for delivery to Alertus-managed endpoints. An Alertus-originated alert must invoke the appropriate outbound CAP configuration, reach the Rave listener, match the intended processing rule and template, and then be distributed to the configured recipients and devices.
Core Components and Responsibilities
|
Component
|
Role in the architecture
|
|
Alertus on-premises server
|
Windows-based server on the college network. The meeting identified the host as alertus.securityengineeringccbcmdedu and the address as 10.21.6.46. Administration is performed through the Alertus web interface. The server contains alert profiles, presets, custom event triggers, device targeting, services, and middleware configuration.
|
|
Rave Mobility Safety
|
Service that receives or originates notifications and applies its configured listeners, processing rules, templates, recipients, and delivery targets.
|
|
CAP integration layer
|
Standardized message-exchange layer used between the platforms. CAP configuration must be associated with the correct outbound profile or inbound listener and with the downstream processing objects that determine what action is taken.
|
|
Network and middleware dependencies
|
The reviewed configuration included TCP port 8280, approved IP addresses, whitelist entries, the Rave communication URL, and related entries in the Alertus middleware properties file.
|
|
Credential management
|
The integration password had been updated to meet new requirements. The meeting identified the need to coordinate with Chris Herman so the current credential is stored in the organizational password vault.
|
Message Flow
1. Rave to Alertus
The session established that this direction was functioning after work with Rave support. The support activity included providing the Alertus URL for configuration on the Rave side, confirming that TCP port 8280 was open, checking required IP addresses and whitelist entries, and validating the Alertus middleware properties file. The status indicators that had previously shown failures were reported as green after the correction.
In normal operation, a Rave-originated alert is passed to the configured Alertus integration endpoint. Alertus then processes the incoming event according to its configured services, triggers, profiles, and target devices.
2. Alertus to Rave
This direction remained unresolved at the end of the meeting. The intended logical sequence is:
-
An alert is initiated in Alertus by using a preset, alert profile, or configured trigger.
-
The selected Alertus configuration invokes the outbound CAP integration associated with the Rave listener.
-
Alertus submits the CAP message to the configured Rave listener endpoint.
-
Rave evaluates the incoming event against its listener and processing configuration.
-
The matching rule selects the appropriate notification template, recipients, and delivery devices.
-
Rave distributes the resulting notification through the channels defined by that configuration.
Note: Important test distinction
A successful Alertus desktop notification confirms that Alertus can execute a local Alertus delivery action. It does not, by itself, confirm that the outbound CAP message reached Rave or that Rave processed and distributed it.
Configuration Relationships
The session showed that configuration complexity is a major support consideration. Similar names and multiple test or production objects can obscure the path taken by an alert. Technical staff should trace the complete chain rather than validating individual objects in isolation.
|
Configuration Object
|
What must be verified
|
|
Alertus preset / profile
|
Defines the initiating alert behavior and selected actions.
|
|
Custom event trigger
|
Associates an event condition with the appropriate Alertus response or channel.
|
|
Outbound CAP configuration
|
Identifies the Rave listener destination and message exchange path.
|
|
Rave CAP listener
|
Receives the inbound message from Alertus.
|
|
Rave processing rule
|
Determines how the inbound event is interpreted and what downstream action is selected.
|
|
Rave notification template
|
Defines the notification content and delivery configuration associated with the matched event.
|
|
Recipients and devices
|
Determines who or what receives the resulting notification.
|
Validated Findings from the Session
-
The Alertus platform is an on-premises Windows server and is managed through a web graphical interface.
-
The Alertus host resolved to an on-campus address during the session.
-
Rave-to-Alertus status was reported as healthy after URL, port, IP, whitelist, and middleware checks.
-
TCP port 8280 was specifically identified as a required network dependency in the reviewed configuration.
-
An Alertus test produced a desktop alert when it was limited to a test device.
-
That local desktop result did not confirm Alertus-to-Rave transmission.
-
The Alertus server could reach the configured destination endpoint. A browser request produced an application-level response because a proper CAP payload was not supplied, but the test demonstrated endpoint reachability.
-
No certificate warning was observed when the reviewed Alertus web address was accessed.
-
The unresolved boundary was the outbound Alertus-to-Rave CAP workflow and its listener, rule, template, recipient, or device mapping.
Troubleshooting Guidance
Use the following sequence when this integration fails. The sequence separates transport validation from application processing so that a successful network test is not mistaken for successful message delivery.
|
Stage
|
Technical action
|
|
1. Establish direction
|
Determine whether the failed path is Rave-to-Alertus, Alertus-to-Rave, or both. Test each direction independently.
|
|
2. Protect production recipients
|
Use a test preset, test account, and explicitly limited device targets before sending any notification.
|
|
3. Validate transport
|
Confirm DNS resolution, destination URL, TCP port 8280 where applicable, approved source and destination IP addresses, firewall access, and whitelist entries.
|
|
4. Validate Alertus middleware
|
Review the Alertus middleware properties file and confirm that the required IP addresses and endpoint information are present.
|
|
5. Trace the Alertus object chain
|
Identify the exact preset or profile, custom event trigger, outbound CAP action, and listener URL used by the test.
|
|
6. Trace the Rave object chain
|
Identify the receiving CAP listener, processing rule, selected template, configured recipients, and target devices. |
|
7. Review logs with vendors
|
Correlate the test time with Alertus and Rave logs. If transport is successful but no message is processed, engage the vendor responsible for the application layer where the trace stops.
|
|
8. Document the resolved mapping
|
Record the confirmed object names, identifiers, endpoints, dependencies, and credential-vault reference after remediation.
|
Operational Documentation Requirements
To reduce recovery time during future incidents, maintain a controlled integration record containing the following information. Do not place active passwords directly in the knowledgebase article; record the approved password-vault location instead.
-
Alertus server name, IP address, operating system ownership, and support contacts.
-
Rave and Alertus endpoint URLs and the purpose of each endpoint.
-
Required TCP ports, firewall rules, approved IP addresses, and whitelist entries.
-
Alertus middleware properties relevant to the integration.
-
Alertus presets, profiles, custom event triggers, and outbound CAP configurations.
-
Rave CAP listeners, processing rules, notification templates, recipients, and device targets.
-
Test accounts, test devices, and a safe validation procedure that cannot notify production recipients.
-
Credential owner, rotation date, and password-vault reference.
-
Vendor case numbers, confirmed log locations, and the final resolution for each incident.
Escalation Boundary
When DNS, routing, endpoint reachability, port access, whitelist entries, and Alertus middleware settings have been validated, but Alertus-originated messages still do not appear in Rave, the most useful next step is coordinated application-level review with Alertus and Rave support. Provide both vendors with a controlled test time, the exact Alertus profile or trigger, the outbound CAP destination, the Rave listener and rule expected to match, and the relevant log entries from both sides.
