This is a public Forum  publicRSS

Topic

    Heena Karir
    CPM... obscure behaviour !!Answered
    Topic posted December 11, 2015 by Heena KarirExpert 
    1240 Views, 12 Comments
    Title:
    CPM... obscure behaviour !!
    Content:

    Hi All,

    We have a CPM code written on Incident Create and Update. But as we are testing it, for few incidents the CPM runs fine but for some it does not get invoked. Has any one faced such issues? What could be possible reason?

    Thanks,

    Heena Karir

    Best Answer

    Pramod Vasudeva Murthy

    <?php
    /**
     * CPMObjectEventHandler: CPMClass
     * Package: RN
     * Objects: Incident
     * Actions: Create, Update
     * Version: 1.2
     * Purpose: CPM Class
     */

    use \RightNow\Connect\v1_2 as RNCPHP;
    use \RightNow\CPM\v1 as RNCPM;
    require_once(get_cfg_var("doc_root") . "/ConnectPHP/Connect_init.php");
    require_once( get_cfg_var( 'doc_root' ) . '/include/config/config.phph' );
    error_reporting(E_ALL);
    initConnectAPI();

    class CPMClass implements RNCPM\ObjectEventHandler
    {
        public static function apply($runMode, $action, $incident, $cycle)
        {
            if ($cycle !== 0) return;
            ob_start();
            
            $inc_ID = $incident->ID;

            echo "********************* CPM run for Incident ID " . $inc_ID . " ****************************"."\n"."\n";                
            echo "Incident Created time --->".$incident->CreatedTime;
            echo "Incident Updated time --->".$incident->UpdatedTime;
            /********************
            
            Logic goes here
            
            
            *********************/
            
            echo "********************* CPM end for Incident ID " . $inc_ID . " on action: " . $action . " ********************"."\n";
            
            $msg = ob_get_contents();            
            ob_end_clean();
            
            $f = fopen('/vhosts/<sitename>/euf/assets/CPM/CPMClass/log.txt','a');
            fputs($f,$msg);
            fclose($f);

            $incident->save();
            RNCPHP\ConnectAPI::commit();
        }
    }

    class CPMClass_TestHarness implements RNCPM\ObjectEventHandler_TestHarness
    {
        static $inc_invented = NULL;
        
        public static function setup()
        {
            $inc = RNCPHP\Incident::fetch(146093);
            static::$inc_invented = $inc;
            return;
        }

        public static function fetchObject($action, $object_type) 
        {
            return (static::$inc_invented);
        }

        public static function validate($action, $object) 
        {
            return (true);
        }

        public static function cleanup() 
        {
            return;
        }
    }
    ?>

    Answer

     

    • Barrilito

      Hi Heena,

      Is it only for certain incidents?  I have not face that issue, but long ago in an older version we had issues where in a time range of every 15 minutes the first incident was triggered, and every incident after that within the 15 minutes range was not. Oracle found a defect and an upgrade was required. So, if that is the case perhaps raise a service request at Oracle.

      Otherwise perhaps post the code so perhaps someone can help out here.

      Regards!

    • Pramod Vasudeva Murthy

      Hi Heena,

      I think it's a good practice to use logs inside CPM. I used logs to write data present inside variable to a log file in assets folder. There by I can keep track of all the happenings by CPM. Let me know if you need a sample.

    • Barrilito

      Hi Pramod,

      True, logging is good. Be aware though that the assets folder is general available and not ip restricted. If you put a logfile there, anyone can see it (if you know the url of course). So if you log client/private information, that may be an issue. So take that into account please. Regards!

    • Pramod Vasudeva Murthy

      Agreed, BvD. But it is sad that there are no better ways to debug CPM; neither I can use built in logs nor I can print a value on console unless by TestHarness.

    • Heena Karir

      Thank you Pramod and BvD !!

      Pramod: I would appreciate if you can share the sample code for logger !!

      ~Heena

    • Pramod Vasudeva Murthy

      Heena - There you go

      Some steps before proceeding:

      • Create a folder in asset called CPM for all CPM logs and create another folder in CPM class name say CPMClass then the path would look like this: /vhosts/<sitename>/euf/assets/CPM/CPMClass/log.txt
      • I am using ob_start(); - which will basically capture all outputs thrown to console(without actually printing to console) and then you will be able to capture in a variable; which values of varible are written to a log file.

      Regards,

      Pramod V

    • Pramod Vasudeva Murthy

      <?php
      /**
       * CPMObjectEventHandler: CPMClass
       * Package: RN
       * Objects: Incident
       * Actions: Create, Update
       * Version: 1.2
       * Purpose: CPM Class
       */

      use \RightNow\Connect\v1_2 as RNCPHP;
      use \RightNow\CPM\v1 as RNCPM;
      require_once(get_cfg_var("doc_root") . "/ConnectPHP/Connect_init.php");
      require_once( get_cfg_var( 'doc_root' ) . '/include/config/config.phph' );
      error_reporting(E_ALL);
      initConnectAPI();

      class CPMClass implements RNCPM\ObjectEventHandler
      {
          public static function apply($runMode, $action, $incident, $cycle)
          {
              if ($cycle !== 0) return;
              ob_start();
              
              $inc_ID = $incident->ID;

              echo "********************* CPM run for Incident ID " . $inc_ID . " ****************************"."\n"."\n";                
              echo "Incident Created time --->".$incident->CreatedTime;
              echo "Incident Updated time --->".$incident->UpdatedTime;
              /********************
              
              Logic goes here
              
              
              *********************/
              
              echo "********************* CPM end for Incident ID " . $inc_ID . " on action: " . $action . " ********************"."\n";
              
              $msg = ob_get_contents();            
              ob_end_clean();
              
              $f = fopen('/vhosts/<sitename>/euf/assets/CPM/CPMClass/log.txt','a');
              fputs($f,$msg);
              fclose($f);

              $incident->save();
              RNCPHP\ConnectAPI::commit();
          }
      }

      class CPMClass_TestHarness implements RNCPM\ObjectEventHandler_TestHarness
      {
          static $inc_invented = NULL;
          
          public static function setup()
          {
              $inc = RNCPHP\Incident::fetch(146093);
              static::$inc_invented = $inc;
              return;
          }

          public static function fetchObject($action, $object_type) 
          {
              return (static::$inc_invented);
          }

          public static function validate($action, $object) 
          {
              return (true);
          }

          public static function cleanup() 
          {
              return;
          }
      }
      ?>

    • Heena Karir

      Thank you Pramod.. 

      Great Help !!

      ~Heena

    • Pavansatish Annavarapu

      Hi Guys,

      Just a thought on the CPM logging. You can create a custom object (Say Log) and store your logs into it. You can then create a report to view the logs.

       

      Regards,

      Pavan

    • Mark Rhoads

      The intent behind the ConnectAPIError and ConnectAPIErrorFatal exceptions is precisely so that customizations can do something intelligent in response to an error.
      Keep in mind that catching these errors and not re-throwing them can hide the error from the CPM framework and make it more difficult for us to help you if there is a problem.  Not re-throwing these errors also prevents the CPM framework from tracking these errors against your customization and protecting the system should the customization persistently fail.

      Be very careful when logging since it can very quickly get out of control and bring your customization down.
      Logging to the operational database (i.e. to an object/table in the same database) will of course interfere with the rest of your operation (i.e. makes it run slower and subject to any issues with how the logging is implemented).
      Logging an unbounded amount of data (i.e. never deleting rows, never removing or truncating files) is not scalable and might cause your customization to fail or even make the rest of your site unusable at some point in the near or distant future.
      But even then, how and when data sizes are limited could still interfere with the expected operation of your site.
      And even then, a short term failure could log so many messages that the logging itself causes the customization to temporarily break.
      I've seen customizations break because they have a query on a logging custom object that is not scalable and they've logged so many messages in a short time that the query breaks until enough time has passed that the query either no longer targets those rows or something else has deleted those rows -- i.e. either too many rows or the query takes too long to run.
      I've also seen customizations break because they write to the same file and the file just keeps growing until something really fails (i.e. out of disk space).
      I've seen customizations break because they create too many files (e.g. one file per request).
      And I've seen customizations break for all kinds of different reasons because they accidentally left too much logging enabled when the site goes into full production (i.e. they did some testing off-hours or on a clone and forgot to turn debugging/logging off in production).
      And worse, sometimes these problems do not show up until months later when the data sizes finally scale up to become a noticeable problem.

      Be very careful and remember that logging is still part of your code, and so still needs to be tested, and that the logging implementation could have defects of its own.

    • Seeking Solution
      Hi Mark,
      Will you suggest to have log in tmp folder? If some integration is in place where you are communicating with third party system and need some logs to look at the request. I see some time getting updated data in CPM is challenge. For example If thread is added to incident getting it within a minute in QA environment is always not works as expected and may need some logging mechanism to trace the exact failing point.
      Mark Rhoads said:

      The intent behind the ConnectAPIError and ConnectAPIErrorFatal exceptions is precisely so that customizations can do something intelligent in response to an error.
      Keep in mind that catching these errors and not re-throwing them can hide the error from the CPM framework and make it more difficult for us to help you if there is a problem.  Not re-throwing these errors also prevents the CPM framework from tracking these errors against your customization and protecting the system should the customization persistently fail.

      Be very careful when logging since it can very quickly get out of control and bring your customization down.
      Logging to the operational database (i.e. to an object/table in the same database) will of course interfere with the rest of your operation (i.e. makes it run slower and subject to any issues with how the logging is implemented).
      Logging an unbounded amount of data (i.e. never deleting rows, never removing or truncating files) is not scalable and might cause your customization to fail or even make the rest of your site unusable at some point in the near or distant future.
      But even then, how and when data sizes are limited could still interfere with the expected operation of your site.
      And even then, a short term failure could log so many messages that the logging itself causes the customization to temporarily break.
      I've seen customizations break because they have a query on a logging custom object that is not scalable and they've logged so many messages in a short time that the query breaks until enough time has passed that the query either no longer targets those rows or something else has deleted those rows -- i.e. either too many rows or the query takes too long to run.
      I've also seen customizations break because they write to the same file and the file just keeps growing until something really fails (i.e. out of disk space).
      I've seen customizations break because they create too many files (e.g. one file per request).
      And I've seen customizations break for all kinds of different reasons because they accidentally left too much logging enabled when the site goes into full production (i.e. they did some testing off-hours or on a clone and forgot to turn debugging/logging off in production).
      And worse, sometimes these problems do not show up until months later when the data sizes finally scale up to become a noticeable problem.

      Be very careful and remember that logging is still part of your code, and so still needs to be tested, and that the logging implementation could have defects of its own.

      View original

       

    • Barrilito

      Hi Seeking Solution,

      As you can see this post was already solved as a best answer was given and is an old post.

      If you have new or related question, please start a new separate post with a clear question.

      Thanks!

      Regards