Getting Started with EDDA (Event and Data Driven Automation)

Discussion created by brendan_sapience_automic on Nov 18, 2017
Latest reply on Jan 30, 2019 by Priyesh_2

What EDDA is good at:

    True Event Driven Automation.

    => Allowing outside systems (programs, applications, scripts, SAAS solutions, etc.) to send events to Automic and trigger Automic Objects intelligently as a response. All of that on a large scale: up to 15k events per second.

How EDDA Works:

   Edda works by providing a simple & secure Rest interface that allows sending Events to AE (from anywhere) and automatically filtering / processing the  content of those events via rules (new object type in AE). The rules map Events to Automic Executable Objects and their variables / Promptsets.

What you need to know before you start:

    Edda is very scalablebecause built on top ofApache KafkaandApache Flink(=Streaming Platform and Rules Engine). This post is not about those technologies so that is as far as we will go here on this topic :).

    Edda is integrated into Automic’s Analytics component, therefore the Rest endpoint is the same and the URLs / requests are very similar. The port for the Rest Endpoint is also the same for Analytics and EDDA.

    Sending Events to Edda willrequire an API key(to keep it secure and within a bounded scope (ex: a particular AE Client)). Such API Key can be generated by a Rest call to Edda.

    Generating API Keys requires you toknow your own System API Key(see below on how to retrieve it).

   Edda introduces 2 new objects to AE: 

        - a newVARA Objectof type: EVENT_DEFINITION

        - a newEVENT Objectof type: SIMPLE_RULE

        => both objects can be found by typing “IA” in the search bar when creating objects (if you must know, IA = Intelligent Automation :))


           => basically describes attributes expected in a given Rest Event

            => ex: “count” as a “number”

            => ex: “success” as a “boolean"


            => describes a set a Rules for filtering events & their content (ex: if attribute “count” is > 2 & if attribute “success” is “True”)

            => also describes an Action (an AE object to execute when a Rest event matches the Rules) (ex: Map “Count” to Variable &COUNT# and execute JOBP Object accordingly)


    Lastly but importantly: get familiar with this post: and download the zip file attached to it (all the examples showed below with are contained within this file and uses Postman).

Part 1: Sending Events to EDDA

   Since Edda exposes a Rest Endpoint, sending events to Edda is done through (POST) Rest Requests, and since Edda is secure, you need to first generate one or several API keys for the Rest Requests to work. In order to generate your API keys, you first need to retrieve yoursystem API key.


    A- Getting your System API Key:


        From the server where AWI (Automic Web Interface) is installed, navigate to the AWI folder structure and locate your “” under the “web-plugin-analytics” folder. You should be able to find it under (in most cases):




        Open the file and locate “backend.api_key”, write down your api key somewhere. The line will look something like this:




     B- Generating your EDDA API Keys:


        Use a POST Request to generate your first EDDA API Key.


        => the request’s header should contain an “Authorization” key with yourSystem API Key (see above) as a value:



        => the request’s Body should contain a JSON structure specifying a “scope”, adescriptionand aclient number(to limit the scope of the Key to a given AE client):



        Execute the request: you should get a response similar to below: Write the “key” somewhere: that’syour first EDDA API Keyyou will use to send Rest Events!



C- Sending / Writing an Event:


    A Rest Event is very simple. It uses the EDDA API Key and a “type" to specify the scope of the event, and sends values through the Body of a POST Request.


    The EDDA API Key needs to be specified in the Header of the request (“Authorization”):




The Body of the request is a JSON structure and needs to contain:


    - “type”: this needs to be the name of the EVENT_DEFINITION (VARA) Object you will create in AE (see EVENT_DEFINITION above for description and below for creation)

    - “timestamp”: in the same format as below, it does not need to be right now, it can be in the past (you can use the one below)

    -a set of values: THIS is the actual content of the Event. It can contain any numberof actual “key/value” pairs but is restricted to3 types:

        -Strings(ex: “message” below)

        -Numbers(ex: “count” below)

        -Booleans(true or false, ex: “success” below)


        => the values you are passing will depend on what you are trying to achieve.. they could contain anything, for example: a ticket number in ServiceNOW, a description of a ticket,  the status of a process running somewhere else, an ID number that needs to be processed, etc.





    At this point, youwill not be able to send an event to AE: we first need to create the Objects in AE that are necessary to the processing of this event. So let’s put this aside for now.


Part 2: Processing Events with EDDA & AE:


   The purpose of EDDA is to Trigger AE Objects based on the content of an event. EDDA Maps the attributes from your Rest Body to the Variables needed for an AE Object to run.


   Ex: I want to pass the value of my attributes “count”, “message” and “success” to a SCRI Object and run it.


   EDDA does this by reading the attributes of an event, mapping them to PROMPTSET Variables of an AE Object and then submitting the AE Object accordingly.

 (All Automic Objects below can be found in the zip file attached to this post).

   A-  Let’s create the SCRI object and its PROMPTSET first then. Here is an example:


        My SCRI Object:    




        And its promptest:


        (Number represents variable &MYCOUNT#, Message represents &MYMESSAGE# and Success is &MYSUCCESS#)



    B- Let’s now create the mapping between our Rest Event and the SCRI execution:


        Create an EVENT_DEFINITION VARA Object.


        In it, specify the structure that you are expecting to extract (the list of attributes from the body and their type, essentially):




        => this (I suspect) is only used internally to list all the attributes that need to be extracted by EDDA from the Event (Ex: the event could contain any number of other useless attributes, only listing the ones we need here offers better performance when parsing the body of the Request)


        Create a SIMPLE_RULE EVENT Object.

           In it, specify the VARA Object you created in the previous step.


            In the “Conditions” tab, specify what constitutes a “Valid” event. This allows you to filter events depending on their content.

            => you need to use this particular syntax for attributes “event.<name of attribute>”. Ex:event.count, event.message, event.success


            In the “Action” tab, specify which AE Object you want to trigger if an Event passes the “Conditions” successfully

            => you should Map your attributes to Promptest Variables for the object you want to trigger.


            Here is a complete example of this:


       Execute your SIMPLE_RULE Object

        => you should see it run in the Process Monitoring and it should have an “Event Count” of 0 (in the Details):



    Go back to Postman and send your Event as previously defined (play with the values in it to see what happens):




    The “Event Count” should increment every time you trigger an event:




    The “RULE” will also trigger “children jobs” every time:




        And each one of these should trigger your SCRI object with the values taken from the Event’s attributes: