K2 integration with SharePoint 2013 is different from what is was in previous versions of SharePoint. Most importantly, there are no K2 services installed on the physical SharePoint servers.
||Important: Important: With the release of K2 Appit 1.4 and K2 blackpearl 4.7, the method of which the K2 for SharePoint app is installed has changed. The K2 for SharePoint app is now deployed on App Catalog level and no longer required to be installed on every SharePoint site. For more information on this change see the K2 for SharePoint App Registration & Activation Management topic.
Instead, the K2 for SharePoint App is installed and provides the link between the K2 server and the SharePoint server.
||Important: The K2 for SharePoint app must be installed on every SharePoint site in order to integrate K2 with SharePoint. If you do not install the app you cannot tell SharePoint that you trust the app to have access to the site. During installation, clicking 'Trust' and running the K2 for SharePoint registration wizard completes the necessary operations to make the integration successful. This is the way the app model works in SharePoint, which means that manually configuring the SharePoint 2013 brokers is not possible.
The most important implication of this architectural change is that all interaction with SharePoint from K2 must happen through remote APIs. See Communicating with SharePoint using SharePoint APIs (MSDN) for more information on these remote APIs. The key takeaway here is that if it can't be done with a remote API, K2 integration cannot enable that feature or functionality.
The app model also has security implications in that the incoming identity from SharePoint, through claims authentication, must be resolved by K2. And the outgoing communication from K2 to SharePoint must use OAuth to use the remote APIs. The key takeaways here are:
- The SmartObject service layer, namely the SharePoint 2013 and SharePoint 2013 Integration brokers, use the CSOM and REST-based APIs to integrate with SharePoint.
- Web page iFrames are employed by SharePoint to show content from a different server and domain, namely the K2 server.
In sum, the App Model Integration with SharePoint 2013 no longer requires installation of K2 bits on the SharePoint server, which is overall less maintenance but has security and functionality considerations. The rest of this topic discusses the functionality implications.
The current workflow wizards that ship with the K2 for SharePoint 2013 integration include the ability to create, update, delete and otherwise manage the following items:
- Lists & List Items
- Libraries & Documents
- Document Sets
There are some limitations when working with some fields and list types. For more information about these see the Help topic Supported Artifacts
These features are currently not available in the remote client APIs for SharePoint 2013. As stated above, this means that K2 cannot offer any integration with these features. If Microsoft does offer support for these in the future, K2 will evaluate at that time whether to include these features in a future K2 release.
- Records Management: There is no remote API to create holds and place items on hold.
- Content Types: The remote API to create Content Type workflows or attach Remote Event Recievers to Content Type events does not exist. K2 supports content type instances at the list and library level today, but cannot attach workflows to content types so that a single workflow can be initiated when a document or list item based on that content type is created anywhere on the site collection.
- Word Services: The API is unavailable remotely to assemble and convert Word documents.
- InfoPath: InfoPath and InfoPath Services does not have a remote API.
Other SharePoint features that have a remote API but are not currently supported by K2, such as Publishing and Search, may at some point be prioritized and added to the product. If you have particular scenarios regarding any feature please let us know about them by sending a request to the Product Management team at K2.