Common Alerting Protocol (CAP) is an XML-based data format for exchanging public warnings and emergencies between alerting technologies.
Omnilert supports sending messages in CAP format. The CAP endpoint allows alerts to be either posted (via HTTP POST) or retrieved from Omnilert via a CAP feed URL.
CAP configuration settings
The first 3 settings in the CAP configuration determine how messages will be delivered. Omnilert offers both "pull" and "push" options for CAP.
To "pull" messages, much like reading an RSS feed, use the Default CAP retrieval URL.
To "push" messages to your listening server, use the optional Default URL to post to setting. Simply enter your listening server's URL. Omnilert will attempt to post messages to that listening server.
Note: If using the "post" option, your server must be reachable by Omnilert. This may require adjustments to local firewall settings at your server's location. Please contact email@example.com if you need an IP address or other arrangements to traverse your firewalls.
The CAP retrieval messages setting determines how many CAP alerts Omnilert will keep in your CAP feed for retrieval ("pull"). Messages will remain posted until replaced, canceled, or expire. If no limit is set, the XML feed will include all recent (unexpired) CAP messages.
Thus, the CAP retrieval messages setting can be used to force Omnilert to either stack multiple CAP messages in the feed or just retain the "Last 1" to force Omnilert to replace any existing message with the most recent CAP alert sent.
Omnilert supports HTTP "basic authentication" for CAP messages sent via HTTP POST. Simply enter the username/password the Omnilert is required to authenticate to your server when posting.
Of course, this is optional. If your CAP listener does not require any authentication, just leave the username and password options blank.
Other CAP settings
The CAP endpoint must be configured to include some required fields to meet the CAP standard. The settings used should reflect the needs of your recipient system.
Fields with dropdowns will show the possible values allowed under the CAP standard. Fields with open text areas allow you to enter your own text values.
For more info on the various CAP fields and their meanings and intended uses, see the CAP standard at http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
Service Status Checks
The Send CAP 'Test' messages as Service Status checks option is used to determine how Omnilert checks the status of any "CAP Post" URL.
By default, Omnilert will send an empty post to check for an "HTTP 200" response. If checked, Omnilert will send a CAP-formatted test message to check if the CAP listener is online.
This setting only applies if using CAP to POST messages to a listener. (If you're pulling CAP messages from Omnilert's feed, this function just doesn't apply to your use case!)
Example of CAP POST XML Content
Most CAP-based systems will read and use the fields provided with the CAP standard. The following is an example of the fields posted when sending CAP messages via HTTP/HTTPS POST.
As you can see, the Subject and Message content from Omnilert is sent in the <headline> and <description> fields of the CAP-formatted XML content sent by Omnilert.
Please sign in to leave a comment.