General Technical Discussions for Service

Get Involved. Join the Conversation.

Topic

    Anurag Mittal
    TriggerNamedEvent of add-in doesn't trigger when invoke...Answered
    Topic posted June 6, 2017 by Anurag MittalGold Crown: 30,000+ Points, last edited September 19, 2018 by Anurag MittalGreen Ribbon: 100+ Points 
    277 Views, 6 Comments
    Title:
    TriggerNamedEvent of add-in doesn't trigger when invoke inside RuleActionInvoked
    Content:

    Hi All,



    I am starting a new thread of a similar issue that this post has. 



    I have a use-case where i have to call an add-in function through workspace rule, for that i am using RuleActionInvoked method. It work's fine. Now after completion of my add-in logic i have to back fire an event to trigger 1 of workspace rule. But this doesn't work at all. I have made sure that event name matches workspace rule and my workspace has just 2 rules one to trigger an add-in and other to handle custom event. 



    It seems 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.



    Scott Harwell  , i tried using your sample code and workspace setup, but still I didn't get any success. I have uploaded your add-in and workspace to my instance, subject of incident is always null. 



    I have attached the sample add-in code and workspace setup, in case any one wants to give a try on their instance to see if it works. 



    I am using Aug 2016 SP5 version.



    ~Anurag

    Document:

    Best Comment

    Bastiaan van der Kooij

    hey Anurag,

    +1 for a great Question with code attached

    Just tested it and that seems to be a bug (did you submit a ticket?). As a workaround you might add a second rule after you call the Add-In to check on the result of your Add-In logic;

    So you would have two WorkspaceRules (example on button click)

    1. IF Button1 click, THEN Execute Add-In Control action
    2. IF Button1 click, BUT ONLY if Add-In Control condition"Result" returns value equals 1, THEN perform you follow up logic


    Then in your Add-In you can perform your logic, set a result variable and have that returned in the second rule;

            string Result;
            public void RuleActionInvoked(string ActionName)
            {
                System.Threading.Thread.Sleep(5000);
                if (AllWasExecutedWell)
                    Result = "1";
            }
            public string RuleConditionInvoked(string ConditionName)
            {
                return Result;
            }

     

    Edit: Just saw Scott's comment on the other post, might be Scott that you use a newer version where it is fixed? I used Nov16 and had the same issue

    Bastiaan

    Comment

     

    • Bastiaan van der Kooij

      hey Anurag,

      +1 for a great Question with code attached

      Just tested it and that seems to be a bug (did you submit a ticket?). As a workaround you might add a second rule after you call the Add-In to check on the result of your Add-In logic;

      So you would have two WorkspaceRules (example on button click)

      1. IF Button1 click, THEN Execute Add-In Control action
      2. IF Button1 click, BUT ONLY if Add-In Control condition"Result" returns value equals 1, THEN perform you follow up logic


      Then in your Add-In you can perform your logic, set a result variable and have that returned in the second rule;

              string Result;
              public void RuleActionInvoked(string ActionName)
              {
                  System.Threading.Thread.Sleep(5000);
                  if (AllWasExecutedWell)
                      Result = "1";
              }
              public string RuleConditionInvoked(string ConditionName)
              {
                  return Result;
              }

       

      Edit: Just saw Scott's comment on the other post, might be Scott that you use a newer version where it is fixed? I used Nov16 and had the same issue

      Bastiaan

    • Scott Harwell

      Thanks for testing on your end and some site version info.  Just tested on a 16.8 site myself and did see the same behavior.  I'll see if I can get some insight on the discrepancy between my tests yesterday and today.

    • Scott Harwell

      An update from our end...

      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 their 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.  Basically, what Bastiaan suggests above.

    • Anurag Mittal

      Thanks Bastiaan/Scott for testing on your side, confirming and giving a work around. 

       

    • Vijaya

      HI

      My requirement : when a field1 changes to specific value then field 2(readonly textbox) has to populate with logged in user name.

      I created an addin in which when a field changes and changes  to yes then execute my addin. In rukeactioninvoke I gave the actionname and got the loggedin username. how I need to return that value??

      Is this possible to set value with dynamically (with out saving the record)?? Please help

      ThanksInAdvance

    • Danette Beal

      Hi Suresh,

      I would encourage you to start a new thread as this one is closed out with a best answer. This will give you a better chance of having one of our experts chime in.

      On another note, Great work Anurag, Scot and Bastiaan on the teamwork in closing this one out!!

      Regards,

      Danette, Community Manager