6 Replies Latest reply on Jun 7, 2012 6:27 PM by Stephane Guedon

    Building a BEM Blackout Web Interface


      I am putting together a specification document for building a web based blackout interface for BEM.

      I am only focusing on how the interface is going to work with BEM, and I want to run it by you guys out there before we begin coding the new system, also I have some questions regarding few things such as using timeframes and time zones.

      I realize I have to use a dynamic blackout policy, I set one up, no problem, and I understand that I can use mposter to insert blackout match table records into BEM's flat file database.  I also know that I have to insert the required timeframes (active &OR inactive) before I insert the blackout record, and what I am planning to do is to insert an active &/OR inactive timeframe for each blackout record that might be inserted using the web interface to easily track these records and delete them from BEM when the blackout expires.  I have done some testing and I simply created a file for each scenario and it seems to be working ok.

      For the timeframe (TIME_FRAME) *& DDBL_MATCH_TABLE, I assumed that I do not need to worry about these fields: data_handle,mc_udid,mc_creation_time,mc_modification_time,publish_env_id

      Since I noticed that BEM basically fills these fields up automatically and assigns a values to them such as  data_handle as an example and others.  The reason I came to this conclusion is because at some point the system we are building needs to clean up any expired blackout records and associated timeframes.

      To delete DDBL_MATCH_TABLE record I am using name and the input_match fields, to delete a TIME_FRAME record I am only using the name field.


      The above is just a high level overview of what I am trying to accomplish, can you please let me know if I am on the right track and if all the above makes sense and the way I am planning to integrate with BEM?

      Does anyone knows what are these 2 fields and if can use them for any reason, what these 2 fields where designed for anyway?

      active_global_timeframes=[]; & except_global_timeframes=[]


      Also, if I am going to have users in several timezones and my BEM server is living in EST TZ, what would be the best way to not have TZ issues? I relialize BEM's Timeframe is based on "Internet Calendaring and Scheduling Core Object Specification (iCalendar) http://www.ietf.org/rfc/rfc2445.txt" please confirm that this is the right doc I need to have the programmer refer to? And can you please give me an example of how to make use of the Time Zone Id (tzid) field in the TIME_FRAME class?

      Shall I suggest the use of the -j option or persistent buffer whenever mposter is being called?




      Amir Khamis

        • 1. Re: Building a BEM Blackout Web Interface

          We implmented our balckouts slightly differently.


          We wrote our own MRL rules to process them.  The reason for this is that we wanted to be able to see what blackouts are currently in effect.


          We tried to use the policy and it worked (i.e it blacked out the things we watned it to), but it was very hard to see "what blackouts are in place now".


          We build a web page as a front end and simply called msend to inject the blackout messages to BEM.





          • 2. Re: Building a BEM Blackout Web Interface



            Is that possible for you to share MRL Rules with us


            Thanks & Regards,

            Balaji Ganesan

            • 3. Re: Building a BEM Blackout Web Interface

              Rather than post our code, as it is very specific to what we do, please let me explain in greater detail what we did.


              First you need to decide on what slots you will use to use for your blackout criteria.


              We created two new event classes: blackout_start and blackout_end. 


              First we make these two events self closing.  That is a blackout_end closes a blackout_start and vice versa.  In this (new) rule we use a (where) clause for all of the criteria you decided to use.


              The actual blackout (refine) rule runs against all open events except blackout_start and blackout_end.  (you don't want to blackout the blackout events!!!).  This rule has a using clause where you list all of the criteria you decided to use.  In the body of this rule you just change the status of the event being processed to ‘BLACKOUT'.


              Finally we have a (new) rule that is used to increment the repeat_count in case we get duplicate blackout messages.


              Once these rules are in place you can use msend (called from the cli or from a web page) to submit a blackout_start or blackout_end message (just make sure to fill out all the blackout criteria in the msend command).






              • 4. Re: Building a BEM Blackout Web Interface

                I've have made that quite similar several times except one enhancement.

                The blackout_start adds an entry to a dda table. A refine rule sets all new events coming in to Blackout if there is a match in the dda table.

                The dda entry is removed automatically when the blackout_start is closed.




                • 5. Re: Building a BEM Blackout Web Interface

                  We thought about using DDA tables, but we wanted everyone to easily see what blackouts are currently in place.


                  If we used the DDA tables we would have to give access to viewing those, and we preferred not to do that.


                  Now they can see all the current blackouts by looking in the IX where the see all the other alerts.  One thing we have thought about (to make this even easier) is building a custom collector for just the blackout alerts.

                  • 6. Building a BEM Blackout Web Interface
                    Stephane Guedon

                    A solution already exist for some year




                    Simple to install and to use