Integrations and APIs for Service

Get Involved. Join the Conversation.

Topic

    Amarinder
    _recordContext.TriggerNamedEvent Not triggering the named...Answered
    Topic posted September 13, 2011 by Amarinder Red Ribbon: 250+ Points 
    1038 Views, 7 Comments
    Title:
    _recordContext.TriggerNamedEvent Not triggering the named event
    Content:

    Hi Members,

    I have developed an add-in which requires  a custom object to be associated to an incident. I want to make sure if thecusom object is empty (no text value in the text box of add-in) then the workflow/script should not move ahead. For this I used the following approach:

     

    1. Added the following code in the add-in : _recordContext.TriggerNamedEvent("NoAcceptance");

    2. Defined a workspace rule :  if "NoAcceptance" named even fires, then make 'field xx' required.

     

    But the above is not working. I checked the add-in code in debug mode and found that code is triggering the above mentioned statement but still the workspace rule is not making the field mandatory.

     

    Could you please advise what may be the reason for the same?

     

    Thanks,

     

    Amarinder Singh




    Best Comment

    Scott Harwell

    For those that might happen to stumble on this post, the conversation for Anurag's issue is here.  I have attached the conclusion below...

    It looks like this behavior is in the product through 17.5 (the most recent as of this post).  And, as we have seen in the other thread, it looks like this has been around for some time.  The ability to immediately call TriggerNamedEvent from within RuleActionInvoke is likely going to remain for the immediate term.  So, anyone that stumbles on this post should plan for that in there architecture; the best practice at this point is to avoid that approach.  The recommended approach would be to create two different rules, where rule A, which triggers the RuleActionInvoke method performs its operations, which is then followed by a separate rule which would occur through order of events, as opposed to being directly triggered by the add-in.

    Comment

     

    • Kabir Vaderaa

      Was there ever a solution to this? I think I have an issue with something similar.

      In one case I have an add-in that waits for a workspace rule and then via it's RuleActionInvoked method calls _recordContext.TriggerNamedEvent("RuleNameHere");

      There is a workspace rule on the contact that is waiting for this named event. As a test it just displays a message box when this event fires.

      This named event doesnt seem to get recognised by the workspace rule on the contact when it fires from RuleActionInvoked and the message box doesnt show but if I do the same call from  

      void _recordContext_DataLoaded(object sender, EventArgs e)
              {
                  _recordContext.TriggerNamedEvent("RuleNameHere");
              }

      which is called in the add-in constructor the workspace rule on the contact waiting for this named event does recognise it and the message box displays.

       

      Any ideas?

    • Chris Omland

      Are you positive the workspace rule is firing? Is there something else you can do to ensure the workspace rule has fired? Also, you can put a break point in the RuleActionInvoked implementation to see if it is ever executed.

       

      -Chris

    • Anuj Behl

      Hi Chris,

      I am experiencing the exact same behavior. When the named event is triggered via RuleActionInvoked method, workspace rules fail to acknowledge that event and it works fine if I trigger the same named event from the constructor or DataLoaded event.

      I can see that the named event is triggered in Add-In Logging, it's just that the workspace rules does not gets triggered.

      Any ideas? Is it a known bug?

      -Anuj

    • Anurag Mittal

      I am facing the same issue. This issue is open since 2011. Can someone from Oracle respond to this to confirm whether its a bug or we are missing something from our end.

      ~Anurag 

    • Scott Harwell

      Just ran through a quick test on my end and the circumstance outlined above does not occur in a simple example scenario.  In this case, the workspace has a rule action that fires on load, which calls the add-in's RuleActionInvoked method.  When the ActionName matches my test, the add-in then calls a rule called TestEvent, which sets the subject of the incident to a hard value.

      So, I would conclude that this has worked for some time, if not all the way back to this original post.  Likely, there is a typo in your rule name or an issue with order of events that is causing something to happen (or not to happen) when you expect.  Attached is the example code and workspace that I used to test.

      If you're stuck troubleshooting this issue, I would suggest starting a new thread where you can provide your workspace and code samples so that the specific problem for your use case can be addressed.  I'd bet your implementation is different from Anuj's and Kabir's, but the symptoms are all similar.

    • Anurag Mittal

      Hi Scott, thanks for answering. But still this doesn't work on Aug 2016 version. Have started a new thread here.

    • Scott Harwell

      For those that might happen to stumble on this post, the conversation for Anurag's issue is here.  I have attached the conclusion below...

      It looks like this behavior is in the product through 17.5 (the most recent as of this post).  And, as we have seen in the other thread, it looks like this has been around for some time.  The ability to immediately call TriggerNamedEvent from within RuleActionInvoke is likely going to remain for the immediate term.  So, anyone that stumbles on this post should plan for that in there architecture; the best practice at this point is to avoid that approach.  The recommended approach would be to create two different rules, where rule A, which triggers the RuleActionInvoke method performs its operations, which is then followed by a separate rule which would occur through order of events, as opposed to being directly triggered by the add-in.