SharePoint 2013 Workflow: Code Activity Vs Service Call

SharePoint 2013 has introduced a new workflow model. The workflow model is mostly declarative (XML based). However, you might need to write custom code to implement complex business logic which the workflow itself doesn’t support. You have two options to implement code in this new workflow model:

• Code activity
• WCF Service

Now having these two options to implement, you need to know the pros and cons of both.

Let me compare these two options considering full-trust solution.

Options/Matrix	Code Activity	WCF Service	Comments
Object Model	You can use Client object model or server object model but better to user Client Object model as this gives you the flexibility to move the workflow manager (along with custom code activity) to non-SharePoint server for scalability.	You can use Server Object Model as the service will be hosted in SharePoint	You should not use Server object model in code activity as the workflow services can be moved to non-SharePoint server for scalability
Development	Since you should use client object model, you need to be familiar with client object model. The development involved few manual steps like creating xml file etc.	Easy to develop – just like regular Visual Studio solution (SharePoint template)
Deployment	Deployment requires copying files in different places, no out-of-box commands to deploy Code Activity	Deployment is easy if you are familiar with WSP deployment	If you don’t have remote access to the server (SharePoint admin will deploy using scripts for you), then code activity deployment might be a bit troublesome
Scalability	If you use Server Object model, you can’t move workflow manager to it’s own non-SharePoint Server. However if you use client object model, you can move workflow manager to it’s own non-SharePoint server.	Since it’s service, you can scale it anyway, like workflow manager and SharePoint server can be hosted in on-premise, cloud or hybrid.
Reusability	If you want to reuse the logic in workflow code activity, you might find it difficult	Since your logic is hosted as WCF service, you can reuse the logic in other modules
Execution	I think code activity will run faster as it’ll be executed inside workflow manager.	Service call will a bit slower than code activity, I believe	This is based on assumption…

 

Workflow Manager in SharePoint 2013 is designed in a way that it can run independently in non-SharePoint server. Basically Workflow Manager and SharePoint communicate over REST endpoints. So if you use server object model in code activity you are breaking the overall architecture and bring the server side dependency. So in code activity it’s recommended to use either client object model or REST.

 

For calling WCF service, you can use built-in activity HttpGet/HttpPost.

 

Conclusion

I personally prefer service approach. I can use server object model, I can reuse the service in other modules and it’s easy to deploy/manage. However, if your custom code activity is doing something non-SharePoint related, like getting data from Line of Business (LOB) system, then maybe it’s better to code activity. It’s because it’s doesn’t make sense to deploy the logic (accessing data in LOB systems) in SharePoint.