Workflow invoking a provider-hosted addin

%3CLINGO-SUB%20id%3D%22lingo-sub-1426846%22%20slang%3D%22en-US%22%3EWorkflow%20invoking%20a%20provider-hosted%20addin%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1426846%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20need%20to%20automatically%20create%20tasks%20in%20a%20task%20list%20once%20a%20list%20item%20has%20been%20created%20in%20the%20main%20list%2C%20and%20to%20fine-tune%20the%20permissions%20of%20the%20created%20tasks%20(at%20the%20individual%20task%20level).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20theory%2C%20all%20of%20this%20could%20be%20achieved%20with%20a%20SharePoint%20workflow%2C%20and%20we%20actually%20have%20done%20something%20like%20this%20before.%20Still%2C%20a%20huge%20downside%20to%20this%20approach%20is%20an%20enormous%20amount%20of%20HTTP%20calls%20to%20SharePoint%20Web%20APIs%20to%20set%20up%20all%20the%20permissions%20correctly%20(we%20use%202013%20workflows%20where%20impersonation%20is%20not%20an%20option)%2C%20as%20well%20as%20overall%20complexity%20of%20the%20resulting%20workflow.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EUsing%20remote%20event%20receivers%20instead%20looked%20like%20a%20good%20idea%20at%20first%2C%20but%20the%20fact%20that%20there%20is%20no%20delivery%20guarantee%20for%20list%20item%20events%20makes%20this%20approach%20totally%20infeasible%20for%20us.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%2C%20I%20have%20come%20up%20with%20an%20idea%20to%20use%20a%20combination%20of%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CUL%3E%3CLI%3Ea%20workflow%20that%20is%20guaranteed%20to%20be%20invoked%20after%20a%20list%20item%20has%20been%20created%3C%2FLI%3E%3CLI%3Ea%20remote%20web%20service%20registered%20as%20a%20provided-hosted%20add-in%20that%20would%20do%20all%20the%20heavy%20lifting%20via%20CSOM%3C%2FLI%3E%3C%2FUL%3E%3CP%3EThe%20workflow%20would%20invoke%20the%20remote%20web%20service%20via%20HTTP%20and%20handle%20failures%20%2F%20retries%20(or%2C%20we%20could%20use%20a%20message%20queue%20to%20decouple%20the%20workflow%20and%20the%20remote%20web%20service).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EDo%20you%20think%20if%20this%20is%20a%20good%20idea%20that%20is%20worth%20implementing%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1426846%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EDeveloper%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E
Highlighted
Visitor

Hi,

 

We need to automatically create tasks in a task list once a list item has been created in the main list, and to fine-tune the permissions of the created tasks (at the individual task level).

 

In theory, all of this could be achieved with a SharePoint workflow, and we actually have done something like this before. Still, a huge downside to this approach is an enormous amount of HTTP calls to SharePoint Web APIs to set up all the permissions correctly (we use 2013 workflows where impersonation is not an option), as well as overall complexity of the resulting workflow.

 

Using remote event receivers instead looked like a good idea at first, but the fact that there is no delivery guarantee for list item events makes this approach totally infeasible for us.

 

So, I have come up with an idea to use a combination of:

 

  • a workflow that is guaranteed to be invoked after a list item has been created
  • a remote web service registered as a provided-hosted add-in that would do all the heavy lifting via CSOM

The workflow would invoke the remote web service via HTTP and handle failures / retries (or, we could use a message queue to decouple the workflow and the remote web service).

 

Do you think if this is a good idea that is worth implementing?

0 Replies