Common Alerting Protocol: CAP POST: 'Service Status' check setting

When configuring your Common Alert Protocol (CAP) endpoint to send CAP-formatted messages as POSTs to a server/listener, Omnilert will check that the listening server is available by default. (There is an option to "Bypass Service Status Check" detailed below, as well.)

Omnilert will post to that server to determine if it's available. This status check happens:

• Whenever you click Update configuration for CAP
• Whenever the Send Message (composer window) or Endpoints screen loads. 

There are two options for this special service status check:

1) Perform a simple GET on the URL to see if the URL returns a 200 "Success". (Default)

    or

2) Send a CAP-formatted message with its <status> set as a "Test", which your CAP-compatible listener should respond to with "HTTP 200 SUCCESS". 

Using CAP-formatted Service Status checks

Most listeners will not need CAP-formatted tests to verify their status. 

However, if your CAP-listening server requires a CAP-formatted POST to respond and be seen, then check the box "Send CAP 'Test' messages as Service Status checks."

(This setting is found at the bottom of the CAP feed's configuration screen in Omnilert.)

Only enable this setting if your listener is expecting and can handle CAP messages with their "status" set to "Test" properly. 

Why? Because this setting will send messages. Each time Omnilert loads its message composer and/or endpoint lists, the system will send a CAP message with content similar to that shown below.

Note that the message is a "test" and expires in one minute.

<?xml version=\"1.0\" encoding=\"UTF-8\"?>
 <alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
 <identifier>bd9b9ce8f7e664d3cf07</identifier>
 <sender>Omnilert</sender>
 <sent>2019-05-07T11:08:30-04:00</sent>
 <status>Test</status>
 <msgType>Alert</msgType>
 <source>pingServer</source>
 <scope>Public</scope>
 <info>
 <category>Other</category>
 <event>TestEvent</event>
 <responseType>None</responseType>
 <urgency>Unknown</urgency>
 <severity>Unknown</severity>
 <certainty>Unknown</certainty>
 <expires>2019-05-07T11:09:30-04:00</expires>
 <senderName>Omnilert</senderName>
 <description>Test</description>
 </info>
 </alert>

(Note: The <sent> and <expires> timestamps vary based on the date/time the page loads, of course.)

The CAP <status> field is set as "Test".

This should indicate to your CAP-enabled endpoint that this message is just a technical test to see if its listening and thus should not cause an alarm.  (For details on standard CAP fields' recommended uses, please see http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html)

Note: This setting is only relevant to you if you're using Omnilert's CAP service to post alerts to a listening server. If you're using CAP via "pull", by pulling messages from Omnilert's server as a feed, then this setting doesn't matter for your use-case.

"Bypass Service Status Check" option

Check the "Bypass Service Status Check" to completely disable any status check for the CAP endpoint. If this option is selected, Omnilert will not check the CAP listener URL ("Default URL to post to"for availability. 

If the service status check is disabled, the CAP endpoint will show a gray circle icon as no service status check was performed.