Showing posts with label K2. Show all posts
Showing posts with label K2. Show all posts

Sunday 13 September 2015

SharePoint 2013 Workflow options - notes

Overview:  There are a lot of workflow options and each of the solutions lend themselves favorably to different circumstances.  In this post I look at the more common options around workflow for SharePoint.  The 3 options I'm exploring are: K2 blackperl, Nintex and SP2013 WorkFlow Manager.  Also note that existing SP2010 workflow still exists and is an option if your business has workflows on the platform already or you have this skill set available.  There are other products but these are the main stream options.

So each of these products has their place and suit different organisations.  This post is my opinion and I am not a workflow expert and show my thoughts on when I would favor 1 of the approaches.

Licencing:  Workflow Manager does not have the licencing costs.  Nintex has a server and CAL licencing model and K2 has a server licencing model.

Skills:  what are your existing in-house skills.  If you already have K2 or Nintex expertise it makes these products far more attractive.

Size:  How big is your organisation, how complex are the workflows, how many workflows and how often do they change shall influence the workflow option to select.

SharePoint 2013 Workflow Manager
SharePoint 2013 introduces an new standalone workflow engine based on Windows Workflow Manager 1.0 using .NET 4.5.  In the SP 2013 world, Office Web Apps (OWA) and Workflow Manager runs as a service separate from SharePoint 2013.
  • SharePoint Designer 2013
  • Ideal for simple or medium complexity workflow processes
  • Limited to a pre-defined set of activities and actions
  • Relatively quick and easy to configure
  • Custom workflow development through Visual Studio
  • Can implement state-machine workflows
  • Supports custom actions/activities
  • Supports debugging
  • Ideal for modelling complex processes
  • Requires a developer
  • Workflow Manager
  • High Density and Multi-Tenancy
  • Elastic Scale
  • Fully Declarative Authoring
  • REST and Service Bus Messaging

Nintex
  • On-premise and cloud workflows – but cloud workflows do not allow custom actions
  • Nintex uses the SharePoint workflow engine
  • Easy to create Nintex workflows (good tooling) but not so easy to upgrade and maintain if complex – they require a proper dev environment if workflows require changing
  • Tight coupling with SharePoint – so upgrades need to be planned. Some workflows have broken after upgrade.
  • Can create custom activities but these are limited to constraints imposed by Nintex design surface
  • More suited to State machine workflows using reusable custom modules and user defined actions.
  • Nintex uses its own database which you will need intimate knowledge of when it comes to performance issues.

K2
K2 – technology agnostic – best suited if SharePoint is only a part of your technology snapshot, some folks consider K2 a BPM product.
Pros:
  • Off box WF hosting:  Allows for increasing the number of blackperl servers and no resource overlap, flexible licencing model as it is server based
  • Well tried and tested workflow engine
  • Good reporting and troubleshooting
  • Excellent SOA layer (SmartObjects) with multiple products.  This is more an EA feature as it can be a great way to create an SOA.  Allows API to connect to custom SQL, CRM, SAP, Web Services.
  • Proven advanced tooling, good visual tooling (not as good as Nintex IMHO)
Cons:
  • Cost is relatively high, support costs are extensive, need to pay for dev and pre-prod licence
  • Not based on the latest MS workflow engine
  • Not easy for end users to build WF (despite marketing noise)
  • Setup and monitoring is specialised and will require advanced K2 expertise
    Difficult to back out of product
  • Tooling requires training and breaking out of OOTB features requires a high level of expertise and dependency on K2
  • Support tended to be patchy with technical knowledge
Updated: 2017-11-03.  Possible Extranet facing blackpearl Infrastructure design
Summary:
K2 is a good product if you need to build an SOA layer for integration, are prepared to install correctly (cost) and maintain.  You shall need dedicated workflow people to create the workflows.  So in the right circumstances it has it’s place.

Updated 11 December 2019:
Microsoft Power Automation (formerly Microsoft Flow) is the default workflow option when working with the Microsoft Power Platform (Power Apps, Power Automation and Power BI).  O365, SPO and D365 can also use Microsoft Power Automation.  Azures Logic Apps is also a good option especially if your application is C#/Azure based and not within one of the SaaS Azure offerings.

Tuesday 11 March 2014

Capturing data for SharePoint

I got an email from an old school friend that heard I may do some SharePoint stuff. 

"I need your advice on a Sharepoint question.  We have a client that need users to capture forms and the ablity to create new forms on the fly, does this sound possible?"

My dashed off reply is below  - comments are welcome

On the SharePoint thing, this is the deal with forms. InfoPath was the standard for creating web forms for SharePoint, saying that about 3 weeks ago, MS announce it is no longer the product of choice and it will not be support after 10 years. It really comes down to how hectic the requirement is where you want you data stored.

SharePoint out of the box allows for users to create lists, this are not too complex and the logic is generally pretty simple. It works really well if your requirement is simple web forms, lots of them and not relational data. All native, very little training but customizing the default look and functionality gets expensive real quick (inject custom JS), there is also a tool SharePoint designer that can be used to customers the forms. When you create a list the CRUD forms are all created for the list.

InfoPath - tool to draw forms custom logic, lots of issues when it get complicated but if you need a lot of forms fast and need some logic this is still a good option.

K2 and Ninetex have forms engines, I have used smartforms from K2, For forms for workflows and building complex forms this is a good option but more if you have a dedicated forms team/guy. If you told me you need 1000 forms with complex logic and more forms need to be added in time, there is workflow and you will have dedicate form requirements this is a good option but be careful it is not as easy as folks may make out.

Pdf share forms work with SP, so if your client has pdf forms - make sure you look at this.  I've never used this approach but it seems plausible.

Custom options, such as SharePoint Designer aspx, you can build and deploy aspx pages, slow but good for customization. Good option if you have a unique complex requirements (think a drawing tool) as basically you have full C# control. You can also create web apps and consume them in SharePoint.

With what I think your skill sets is at .., it is probably also worth looking at using MVC or creating the forms in .NET code (webforms), then display using iFrame or the new app model in SP2013. You secure the app using claims based auth/OpenId/OAuth.
Those are your basic options. Send me some more detail and I can try give you a clearer match.

Also see:
http://go.limeleap.com/community/bid/286331/Forms-in-SharePoint-Seven-Ways-to-Create-a-Form-in-SharePoint
http://blogs.office.com/2013/03/04/options-to-create-forms-in-sharepoint-2013/#comments

With SharePoint 2013, look at CSR.

Ultimate Forms from InfoWise offers a good option for form capture and output.
Stratus Forms looks like a great tool.

Update 09 March 2016:
·         SharePoint 2016 on-prem. shall support InfoPath Forms Services until 2026 (extended support only from 2021).
·         InfoPath Forms on Office 365  supported until further notice.
·         No InfoPath 2016 as part of Office 2016, use the InfoPath 2013 desktop application to build forms.