The platform administrator is the human(s) that has to be notified about stuffs happening within the automation platform. Marcel can share its concerns through several ways described in this page.

Marcel will not generate by itself logs but instead, creates outputs to standards stdout or sterr depending if the message is informational, a warning or an error.
As designed to be part of a distributed system, it publish these output to following topics which name are self explanatory.

<MarcelID>/Log/Information
<MarcelID>/Log/Warning
<MarcelID>/Log/Error
<MarcelID>/Log/Fatal

<MarcelID> being Marcel's id as defined by ClientID configuration directive.

Marcel can send alerts or notification to its platform administrator  using following directives.
In each cases, following substitutions are made :

•     %t% : Title of the message to be send
•     %m% : detailed message payload

Call a REST web service where the payload is provided in the URL itself.

RESTUrl=https://smsapi.free-mobile.fr/sendmsg?user=xxxxxxxx&pass=xxxxxxxxxxxxxx&msg=%m%

This example will call Free (French ISP) free (no charge) SMS service. As you can see, there is no way to provide a title which is simply ignored.

RESTUrl=http://api.pushingbox.com/pushingbox?devid=xxxxxxxxxxx&titre=%t%&msg=%m%

This example is calling a PushingBox service.

Run an OS command which takes the payload for it's standard input (STDIN).

AlertCommand=mail -s "%t%" mail@domain.com

Send a mail using ... mail command which is quite common on all Unises systems (depending your distribution, you might have to install a dedicated package and configure messaging hop).

Unnamed alerts and notifications are the original way to communicate with the platform administrator. As they are not flexible at all, it's encouraged to switch to named notifications as described later in this page.

Unamed Alerts and Notifications should be restricted only to alert about a critical issues rising on the platform.

Actions to be triggered by unnamed alerts or notifications are declared by AlertCommand= or RESTUrl= directives outside named notification section.

While Alerts and Notifications share the same communication mechanisms, they acts sightly differently as described bellow.

Notifications are handling

Notification/title

They do the same thing, the only difference is they are stateless, meaning that each and every message received trigger a sending.

Like unnamed alerts, if the 1st character is

• a 's' : only a mail is sent using AlertCommand
• a 'S' : both a mail (AlertCommand) and an SMS (RESTUrl) are sent

and this first character is always ignored.

Named notifications respond to

nNotification/xyz/title

where xyz is the concatenation of names of notifications to be triggered
As example, publishing to

nNotification/12a/my_title

will send our messages to notifications "1", "2" and "a" with my_title as title.

In the configuration file, they are configured whitin $notification like that

# Pushingbox example
$notification=1
RESTUrl=http://api.pushingbox.com/pushingbox?devid=xxxxxxxxxxx&titre=%t%&msg=%m%

or

# Mail example
# The message body is put in stdin
$notification=3
AlertCommand=mail -s "%t%" mail@domain.com

where the argument of $notification is the name (or identifier) : it can be only 1 character long.