7 Replies Latest reply on Aug 8, 2017 1:24 PM by Aaron Larson

    To Task or not to Task

    Aaron Larson

      Okay - I swear I found a similar post addressing this in the past but am unable to cull it out of the site now. 

       

      The Scenario:

      I am looking to invoke some custom code triggered by a workflow change state. Mostly variable updates, file moves, etc.

       

      The Question:

      Am I better off using a TASK ADD-IN or using a REGULAR ADD-IN WITH HOOKS?  What are the advantages and disadvantages of each method?

       

      Background: I just started getting involved with EPDM 6 months ago.  I am self taught and do have some decent programming experience (i.e. I'm a dangerous hack).

        • Re: To Task or not to Task
          Michael Dekoning

          Aaron,

          Which is better depends on what you are going to do. Tasks were designed to allow processes to run on a different machine. For example, the Convert Task from SolidWorks can run on a different machine so as to not tie up the user's computer exporting files. For this reason, the user must allow the Task to run on the computer and the Task must be set up to run on that machine. This can be a lot to manage if you create a Task that you want all of your users to run. Tasks can be run on a scheduled basis unlike add-ins which can only be started by the hooks available.

          • Re: To Task or not to Task
            Jeff Sweeney

            If all things are equal, I'll do a regular add-in every time. They're less overhead.

              • Re: To Task or not to Task
                Aaron Larson

                Jeff - a follow up question to this.  Let's say I have 3 different workflows for different document types.  For each workflow, at some state change, I want to trigger some API action.  If I have an add-in do I have to handle each "case" in the same add-in program?  In other words my add-in would need to grow to accommodate whatever functionality I add across my entire system.   I'd have to build in logic on the state change to see which document type I'm dealing with and also the origination and destination states (in case I have different actions based on different transitions).  With a task, I can program for a specific case every time eliminating the need to build in the logic to figure out what object I'm dealing with each time. 

                 

                I hope that made sense... and also please correct me if I'm missing something.  I'm not trying to merit or demerit the "regular addin every time" methodology, just making sure that I understand the ramifications.

              • Re: To Task or not to Task
                Lee CS Young

                I'll try to do a task as much as possible. Any bugs or code issues are limited to the machine running the task. Otherwise you're forced to update the client add-ins which generally requires the clients reboot their machines.

                Obviously there are ways around that, however.

                • Re: To Task or not to Task
                  Tim Webb

                  Depends on what you are attempting to do. As you stated,

                  The Scenario:

                  I am looking to invoke some custom code triggered by a workflow change state. Mostly variable updates, file moves, etc.

                   

                  In this scenario, there's not really a reason to make your program a task add-in.

                   

                  Hope this helps,

                  Tim CEPA

                  Believe in The Q!

                    • Re: To Task or not to Task
                      Aaron Larson

                      From what I hear - the only time I can see much value is having a specific machine carry out a task would be to convert drawings to PDF possibly.  Lee CS Young does make a good point too from the troubleshooting standpoint, but so far I've had a much easier time developing regular add-ins than trying to get tasks to run.  Thanks for all the feedback.

                        • Re: To Task or not to Task
                          Greg Thomson

                          I'm pretty much in agreement with all the feedback mentioned, but one very nasty point not mentioned about tasks is they get queued asynchronously to other Actions in your workflow, so you can't control ordering or timing of these Actions (i.e. tasks).  So something as simple as approve, print, and move could get re-ordered into move (the PDF that doesn't exist), print (the unapproved drawing) and then approve the drawing.

                           

                          Lesson Learned !

                          Greg,