CA Service Management

Expand all | Collapse all

Attach service type events on incidents

  • 1.  Attach service type events on incidents

    Posted May 19, 2017 07:43 AM

    Hello,

     

    I need help for this particular case.

     

    We decided to attach service types with CI from class application.Those services types depend on incident priority and a custom incident field named zconcerned_application, which is linked to a custom factory zappl. On this factory, I created 4 custom fields zsla_p1, zsla_p2, zsla_p3 and zsla_p4, which contains a specific service type for the priority.

     

    Based on what I've read on CA communities, I started to write this code :

     

    ////////////////////////////////////////////////////////////////////////
    // Method:      cr::zcr_sla()
    //
    // Description: sets the service level of the call request based
    //   on its current prority and its concerned_application
    //
    //    
    // Input
    //     priority                        = argv[3];
    //  support_lev                     = argv[6];
    //     zconcerned_application      = argv[9];
    //  category                         = argv[12];
    //  zenvironnementINC               = argv[15];
    //
    // Return
    //   None
    ////////////////////////////////////////////////////////////////////////
    cr::zcr_sla(...)
    {
         logf(SIGNIFICANT, "%s: ref_num = %s", "cr::zcr_sla",(string)argv[15] );

    // If no prority or concerned application change, return
         if ((argv[2] == argv[3]) && (argv[5] == argv[6]))
         return;

         string _category, _zenvironnementINC;
        
    // Si catégorie différente de "Application/SVA", on sort
         send_wait(0, top_object(), "call_attr", "api", "get_val_for_wc", "pcat", format("persistent_id ='%s'",(string)argv[9]),"sym");
         if (msg_error()) {
              logf(ERROR, "Error for getting category symbol %s : ", msg[0]);
              return;
         }
         _category = msg[0];
             
         if (_category != "Application/SVA")
              return;
        

    // If environment not "Production" or "Homologation", return
         send_wait(0, top_object(), "call_attr", "api", "get_val_for_wc", "zdata_environnementINC", format("id =%d",(string)argv[12]),"sym");
         if (msg_error()) {
              logf(ERROR, "Error for getting zenvironnementINC symbol %s : ", msg[0]);
              return;
         }
         _zenvironnementINC = msg[0];

         if (_zenvironnementINC != "Production" && _zenvironnementINC != "Homologation")
              return;

         string ,_priority, _zconcerned_application;

         _priority = (string)argv[3];
         _zconcerned_application = (string)argv[6];
        
         string new_sla;
         string zapp_persid;
         string zsla_p1,zsla_p2,zsla_p3,zsla_p4;
         
         if(_priority == "1") {
              send_wait(0, top_object(), "call_attr", "api", "get_val_for_wc", "zappl", format("id=U'%d'",_zconcerned_application),"zsla_p1");

              if (msg_error()) { 
                logf(ERROR, "Error for getting zconcerned_application sla %s",msg[0]); 
              } 
              else  {
                   new_sla = msg[0];
              }
         }
         else {
              if(_priority == "2") {
                   send_wait(0, top_object(), "call_attr", "api", "get_val_for_wc", "zappl", format("id =U'%s'",_zconcerned_application),"zsla_p2");

                   if (msg_error()) { 
                     logf(ERROR, "Error for getting zconcerned_application sla %s",msg[0]); 
                   } 
                   else  {
                        new_sla = msg[0];
                   }
              }
              else {
                   if(_priority == "3") {
                        send_wait(0, top_object(), "call_attr", "api", "get_val_for_wc", "zappl", format("id =U'%s'",_zconcerned_application),"zsla_p3");

                        if (msg_error()) { 
                          logf(ERROR, "Error for getting zconcerned_application sla %s",msg[0]); 
                        } 
                        else  {
                             new_sla = msg[0];
                        }
                   }
                   else {
                        send_wait(0, top_object(), "call_attr", "api", "get_val_for_wc", "zappl", format("id =U'%s'",_zconcerned_application),"zsla_p1");

                        if (msg_error()) { 
                          logf(ERROR, "Error for getting zconcerned_application sla %s",msg[0]); 
                        } 
                        else  {
                             new_sla = msg[0];
                        }
                   }
              }
         }    

         uuid who; 
         object newobject; 
         string zattached_sla;
         send_wait(0,top_object(), "call_attr", "cnt", "current_user_id"); 
         who=msg[0];
         string cr_persid,cr_id;
         cr_persid = argv[21];
         cr_id = substr(cr_persid,3,strlen(cr_persid));
         logf(SIGNIFICANT, "cr_id %s - cr_persid %s", cr_id, cr_persid); //log new object id 
         send_wait(0, top_object(), "call_attr", "api", "insert_object", who, "attached_sla", NULL, 0, "map_sdsc", new_sla, "ticket_id", cr_id, "ticket_type", "cr", "_mapped_cr", cr_persid); 
         if (!msg_error()) { 
              newobject = msg[0]; 
              zattached_sla = newobject.id;
              logf(SIGNIFICANT, "new attached_sla id %s", zattached_sla); //log new object id 
              cr::add_attached_events(new_sla,cr_persid,zattached_sla,who);
         } 
    }

    cr::add_attached_events(string service_type, string cr_persid, string attached_sla, uuid who) {
         logf(SIGNIFICANT, "cr::add_attached_event %s", service_type); //log new object id

         int count; 
         string _event;
        
    // Get service type events list
         send_wait(0, top_object(), "call_attr", "api", "get_list", "slatpl", who, format("service_type='%s'",service_type), -1);  
         if (msg_error()) {  
              logf(SIGNIFICANT,"Error %s",msg[0]);  
         }  
         else { 
              object obList; 
              count = msg[1]; 
              obList = msg[0]; 
              logf(SIGNIFICANT, "nb event %d",count); 
              send_wait(0, top_object(), "call_attr", "api", "get_list_values", who, obList,0,count,0,"event");  
              if (msg_error())  
                   logf(SIGNIFICANT,"Error %s",msg[0]);  
              else { 
                   int i;  
              // For each event, attach it to incident
                   for (i=0;i<msg_length();i++) {  
                        i=i+2;
                        _event = msg[i];
                        logf(SIGNIFICANT,"Event[%d]: '%s' on %d", i, _event,msg_length());
                       
                        object Objevt; 
                        send_wait(0, top_object(), "call_attr", "evt", "dob_by_persid", 0, _event); 
                        if (msg_error()) { 
                             logf(SIGNIFICANT,"Error %s",msg[0]); 
                        } 
                        else 
                        { 
                             Objevt = msg[0]; 
                             send_wait(0, top_object(), "call_attr", "evt", "new_attached_event_obj", NULL, cr_persid,Objevt, Objevt.delay_time,(date) NULL, "SLA", 0, 0,""); 
                             if (msg_error()) { 
                                  logf(SIGNIFICANT,"Error %s",msg[0]); 
                             } 
                        }
                   }  
              } 
         } 
    }

     

    The result is that the service type event is well attached to the incident, as the first event attached to this service type, but the other events do not, and I don't know why...

     

    The for loop on line 145 is just executed one time, even if there are more events to attach.

     

    The only I have is :

    05/19 11:22:17.78 WIDV179A       spelsrvr            28156 ERROR        sla.spl               3734 Error checking in deleted atev: Attempt to checkin with nothing checked out.
    05/19 11:22:17.81 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           322 cr::zcr_sla: ref_num = 369970
    05/19 11:22:17.95 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           427 cr_id 769900 - cr_persid cr:769900
    05/19 11:22:18.14 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           432 new attached_sla id 487781
    05/19 11:22:18.14 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           438 cr::add_attached_event sdsc:400003
    05/19 11:22:18.16 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           452 nb event 5
    05/19 11:22:18.17 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           462 Event[2]: 'evt:400059' on 15
    05/19 11:22:18.28 WIDV179A       spelsrvr            28156 SIGNIFICANT  gipsi_cr.spl           322 cr::zcr_sla: ref_num = 369970

     

    Could someone explain this behavior to me please ?



  • 2.  Re: Attach service type events on incidents

    Broadcom Employee
    Posted May 19, 2017 10:05 AM

    From reading the code and the output in the stdlog, I would say maybe you can dump the value of msg_length() like

    int i;

    logf(SIGNIFICANT, "msg_length is %d",msg_length());

    I think this value is less or equal to 2 and that explains why only one event attached

    to the service type.

    2cents for help trouble shoot the problem.

    Thanks

    Chi



  • 3.  Re: Attach service type events on incidents

    Posted May 19, 2017 10:55 AM

    Hello,

     

    Thanks for the reply.

     

    That's already done (line 148).

    The output shows:

    Event[2]: 'evt:400059' on 15

     

    In the service type, there are 5 events which should be attached.



  • 4.  Re: Attach service type events on incidents

    Broadcom Employee
    Posted May 19, 2017 11:02 AM

    you have

    i=i+2;
    before all of those...which means your first one is "2" not "0" and the stdlog says
    this is the only one added to the event list.
    I am not sure if the msg[] has all the events there for you to loop. you could turn on
    trace to take a look:
    pdm_trace spelsrvr ON
    and look at the messages to and from to see where are events are.



  • 5.  Re: Attach service type events on incidents

    Posted May 19, 2017 11:39 AM

    I've added a loop to log the content of msg :

    for (i=0;i<msg_length();i++) {  
         logf(SIGNIFICANT,"msg[%d]: %s", i, msg[i]);
    }

     

    Result :

    05/19 17:36:31.61 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           491 cr_id 770149 - cr_persid cr:770149
    05/19 17:36:31.79 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           496 new attached_sla id 487877
    05/19 17:36:31.79 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           502 cr::add_attached_event sdsc:400003
    05/19 17:36:31.81 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           516 nb event 5
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[0]: slatpl:400017
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[1]: event
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[2]: evt:400059
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[3]: slatpl:400018
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[4]: event
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[5]: evt:400060
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[6]: slatpl:400019
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[7]: event
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[8]: evt:400061
    05/19 17:36:31.83 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[9]: slatpl:400020
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[10]: event
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[11]: evt:400062
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[12]: slatpl:400022
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[13]: event
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           523 msg[14]: evt:400063
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           527 msg_length[0]: slatpl:400017
    05/19 17:36:31.84 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           531 Event[2]: 'evt:400059' on 15
    05/19 17:36:31.95 WIDV179A       spelsrvr            15424 SIGNIFICANT  gipsi_cr.spl           394 cr::zcr_sla: ref_num = 369994


  • 6.  Re: Attach service type events on incidents

    Broadcom Employee
    Posted May 19, 2017 11:47 AM

    so it is 2, 5, 8, 11 and 14...i=i+2 works for 2 only...that explains why only the first event is attached. you script would need to be modified accordingly:

    if (i<=0)

    {i=i+2;}

    else { i=i+3;}



  • 7.  Re: Attach service type events on incidents

    Posted May 22, 2017 03:45 AM

    Yes, events are in 2, 5, 8, 11 and 14, but you forgot the loop increment.

     

    The for loop start with i=0.

    i=i+2 -> i=0+2 -> i=2

    And I get msg[2] as expected.

    Then, the for loop increment i, so i=3.

    After that, i=i+2 -> i =3+2 -> i=5 as expected, but I don't get the event, and got no message log talking about accessing wrong element.

     

    So, I don't think this part of code is the issue.

     

    Edit : I tested your suggestion, but same issue, the first event is well attached, but the loop seems to stop just after...

     

    05/22 10:10:17.46 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           394 cr::zcr_sla: ref_num = 369996
    05/22 10:10:17.57 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           491 cr_id 770196 - cr_persid cr:770196
    05/22 10:10:17.80 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           496 new attached_sla id 487926
    05/22 10:10:17.80 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           502 cr::add_attached_event sdsc:400003
    05/22 10:10:17.82 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           516 nb event 5
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[0]: slatpl:400017
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[1]: event
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[2]: evt:400059
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[3]: slatpl:400018
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[4]: event
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[5]: evt:400060
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[6]: slatpl:400019
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[7]: event
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[8]: evt:400061
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[9]: slatpl:400020
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[10]: event
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[11]: evt:400062
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[12]: slatpl:400022
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[13]: event
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           523 msg[14]: evt:400063
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           527 msg[0]: slatpl:400017
    05/22 10:10:17.85 WIDV179A       spelsrvr             6920 SIGNIFICANT  gipsi_cr.spl           535 Event[2]: 'evt:400059' on 15


  • 8.  Re: Attach service type events on incidents
    Best Answer

    Broadcom Employee
    Posted May 22, 2017 04:10 PM

    I took a look at send_wait()...and saw this:"

    send_wait () sends a message and waits either for the (first) reply or a timeout. Arguments are as in
    send (). send_wait () return 0 if a reply was received or != 0 if a timeout occurred. If a reply is
    received msg, msg_length () and msg_error () will be set to correspond to the reply and can be used
    to access it until the next send_wait ().

    "

    please notice the msg_length()...the same one you used in

    for (i=0;i<msg_length();i++)...
    this means, the first time the send_wait() is called, the msg_length() changes accordingly.
    to avoid situation like this, you would need to change the code like this:
    int mylenghth = msg_length();
    for (i=0;i<mylength;i++)...
    hope this helps a bit.


  • 9.  Re: Attach service type events on incidents

    Posted May 23, 2017 04:01 AM

    I had not thought about that and I think you have very well identified the problem, and that should help me a lot.

     

    I test it and come back to confirm.



  • 10.  Re: Attach service type events on incidents

    Posted May 23, 2017 09:26 AM

    Thanks a lot. It works great.

     

    Since msg is also reset by the send_wait, I added a for loop to get events persid before the loop which attach events.

    The code now looks like that :

     

    cr::add_attached_events(string service_type, string cr_persid, string attached_sla, uuid who) {
         logf(SIGNIFICANT, "cr::add_attached_event %s", service_type); //log new object id

         int count; 
         string _event;
         object group_leader; 
         send_wait(0, top_object(), "get_co_group"); 
        if (msg_error()) { 
              logf(SIGNIFICANT,"Error'%s'", msg[0]); 
              return; 
        } 
         else{ 
              group_leader = msg[0]; 
         }
    // Get the event list linked to the service type
         send_wait(0, top_object(), "call_attr", "api", "get_list", "slatpl", who, format("service_type='%s'",service_type), -1);  
         if (msg_error()) {  
              logf(SIGNIFICANT,"Error %s",msg[0]);  
         }  
         else { 
              object obList; 
              count = msg[1]; 
              obList = msg[0]; 
              logf(SIGNIFICANT, "nb event %d",count); 
              send_wait(0, top_object(), "call_attr", "api", "get_list_values", who, obList,0,count,0,"event");  
              if (msg_error())  
                   logf(SIGNIFICANT,"Error %s",msg[0]);  
              else { 
                   int i;  
                   count = 0;
                   string event_persid_list[30];
                   for (i=2;i<msg_length();i=i+3) {
                        event_persid_list[count]=msg[i];
                        logf(SIGNIFICANT,"msg[%d]: %s", i, msg[i]);
                        logf(SIGNIFICANT,"event_persid_list[%d]: %s", count, event_persid_list[count]);
                        count++;
                   }
              // For each event, attach it to the incident
                   for (i=0;i<count;i++) {  
                        logf(SIGNIFICANT,"msg[%d]: %s", i, event_persid_list[i]);
                   
                        _event = event_persid_list[i];
                        logf(SIGNIFICANT,"Event[%d]: '%s' on %d", i, _event,count);
                        
                        duration timeout;
                        timeout = 120;
                        object Objevt; 
                        send_wait(0, top_object(), "call_attr", "evt", "dob_by_persid", 0, _event); 
                        if (msg_error()) { 
                             logf(SIGNIFICANT,"Error %s",msg[0]); 
                        } 
                        else 
                        { 
                             Objevt = msg[0]; 
                             send_wait(0, top_object(), "call_attr", "evt", "new_attached_event_obj", NULL, cr_persid,Objevt, Objevt.delay_time,(date) NULL, "SLA", 0, 0,""); 
                             if (msg_error()) { 
                                  logf(SIGNIFICANT,"Error %s",msg[0]); 
                             }
                        }
                   }  
              } 
         } 
    }


  • 11.  Re: Attach service type events on incidents

    Posted Aug 21, 2018 11:29 AM

    Hi Guys,

     

    Is this Solution Works with classic_sla_processing option disabled/not installed?

     

    Regards,



  • 12.  Re: Attach service type events on incidents

    Posted Aug 22, 2018 10:46 AM

    Hi Guys,

     

    Is this Solution Works with classic_sla_processing option disabled/not installed?

     

    Regards,