Integrations and APIs for Service

Get Involved. Join the Conversation.


    Maheep Kaur
    Execute Object Event Handler in Business Rules
    Topic posted May 13, 2016 by Maheep KaurGold Medal: 3,500+ Points 
    836 Views, 18 Comments
    Execute Object Event Handler in Business Rules


    My query is that if i call an event handler from business rule. In that cpm I set a field. 

    Now in the next business rule , I have to check the value of that field and trigger something.

    Does the synchronous CPM mean that it would complete the processing in the php file and then trigger the next business rule?

    May 2015


    • Barrilito van Dijk

      Hi RD,

      Calling a cpm via the rules synchronous means it will try to run the script and perform its actions within a max time of 5 seconds. Asynchronious means it will be cued. In the event handler that you call you can define wether to use synchronious or asynchronious. I am not sure if the synchronious action takes for instance 3 seconds if the next rule will be called after three seconds or straight away. My bet is that it will take 3 seconds. Perhaps build a test case to check that.

      Good luck. Regards.

    • Pramod Vasudeva Murthy

      Forgive me if I sound silly,

      If you want to run a CPM on a biz rule and after CPM sets a field value and based on that you need to trigger another rule, why not mimic the same behaviour in CPM? Atmost you would need to write a condition and set its value(unless you are sending some OOTB emails).

      I am just guessing there might be few biz requirements which you want to achieve which I am blind to. 

      - VIP

    • Mark Rhoads

      CPM scripts are always run after the transaction is commit.

      Synchronous CPMs are queued up as they are encountered and run after the commit, synchronous to the transaction. In other words, the CPM will always complete before returning from the request that induced the transaction.

      Asynchronous CPMs are also queued up as they are encountered and run after the commit, but they are run asynchronous to the transaction and the request that induced it.  The request that induced the transaction could return before the CPM has had a chance to run -- the CPM is run later by a different process.  Think of it it as deferred work.

      CPMs are not ever run in a "nested" context -- they get queued up per transaction and run after the transaction is committed.

      Rules are run when the operation or API call is made.

      So, with a CPM, a rule for a changed field will not be run until the corresponding ->save() method is called.
      That rule may invoke another CPM (or even the same CPM), either synchronous or asynchronous, but that only queue's the CPM execution until after that transaction is committed.

      To answer the original question, the rule gets run when the corresponding ->save() method gets called, but any CPMs that may be invoked are only run after the inducing CPM has committed or has successfully completed processing.

    • Maheep Kaur

      Hi Pramod,

      Valid Point. But I want to set up an escalation timer rule, which cannot be done in the CPM (I suppose).That is why I have to set a field and check that field and then invoke the escalation timer.

    • Maheep Kaur

      Hi Mark,

      Does that mean if the synchronous CPM takes 3 secs to run, the next rule will be called after 3 secs or straightaway??

    • Narendra Muttineni

      Here, I agree with the Mark. the Business rules will execute only once the Transaction gets committed. even though if you set a field value through the CPM and without calling the Save(), you can't perform the action on that field.



    • Mark Rhoads


      "Does that mean if the synchronous CPM takes 3 secs to run, the next rule will be called after 3 secs or straightaway??"

      RE:A matching rule will be fired as soon as the corresponding save() method is called. Any subsequently invoked CPM will be run after the transaction is commit, in this case after the current CPM has successfully completed.


    • Maheep Kaur

      Let me elaborate my scenario with an example, so that i can clearly understand this.

      1. Agent changes incident status to 'Solved' and clicks on Save.

      2. Business Rules start executing.

      3. Business Rule 1: If status is 'Solved', then call object event handler (This event handler checks some condition and changes the status to 'Pending' and $obj->save)

      4. Business Rule 2: If status is 'Pending', then do something.

      Now what will happen?

      Business Rule 2 will be hit or not?

    • Dietrik

      Why not give it a try ?

    • Maheep Kaur

      Tried. It behaves wierd. So need a process confirmation

    • Barrilito van Dijk

      Hi RD.

      I understand that it may be confusing, and that you want to know the exact process. However, I think most replies give you the process in the basis, but the process is not really satisfying I guess. Perhaps you need to think of another solution / approach for your case which is less depended of processes that are not so straightforward. CPM are all ways powerful but rather tricky, as for instance saving incident data in the cpm is another update on the incident which may trigger another cpm or rule. So, the use of cpm must be straight and clear. It keeps on being an interesting subject, thats for sure! wink


    • Dietrik

      I gave this a try but it seems to run the rules twice, once after the update through a workspace and once after the CPM save command.

      The rule does not "see" the changes made by the CPM within that first run.

      It does see the changes in the second run, which is caused by the CPM update.

      This looked predictable behavior

      To translate to your situation: Business rule 2 will be hit but by a second run of the rules caused by the save command in the CPM

    • Mark Rhoads

      The behavior as described above is expected.

      Rules are run when the object is saved, before CPM gets run.

      So, the first rule sees the object state as it was submit and queues the CPM to run when the transaction is committed.

      All other rules are run.

      All other API's in the same request are run.

      The transaction is committed and any queued CPMs are run (synchronous) or scheduled to run (asynchronous).

      So, that CPM queued by the rule above is eventually run, makes the change and calls ->save(), which starts off the rules again -- this is an entirely new transaction.  If running rules is not desired, then specify one of the "Suppress" options to the save() method.


    • Maheep Kaur


      What I had observed earlier was that both the transaction commit and the CPM Save were happening almost together and the rule log was showing wierd combination of 2 saves at one time.

      But I will try this again and update the exact behavior

    • Mark Rhoads

      Keep in mind that timestamp resolution is only to the second, and all of these operations could occur in the same second.

      Also, generally the timestamp value that is used is the time that the transaction began.  So, most timestamp values from a ->save() to the the commit will have the same timestamp no matter how much delay was added between the ->save() and commit().