Stephane Eyskens's blog
SharePoint 2013 vs IBM Connections 4.5 - Metadata, Office Integration + Mobile support - Comparison from the field
I've already published one blog post about a broader comparison between these products. You can read it here:
It caused some IBM people to react and that's great since this is what I expected. They have pinpointed some items I missed (on purpose for some of them).
If you haven't read my previous post on this topic, please go read http://www.silver-it.com/node/160 it since I'm only going to focus on the write operations here. As you know, in REST, whenever you want to create a resource, you should use the HTTP POST verb.
In my previous post, I explained how to handle ComplexTypes and Collections with HTTP GET using your own _api endpoints in SharePoint 2013. These operations were all READ operations based on HTTP GET.
To declare a method that can only be called by HTTP POST, you need to implement the following methodinformation:
First, I'd like to thank Chris Givens (@givenscj) and Steve Curran (@spsteve) for their help on this topic. Chris has recently published an excellent blog post on this topic http://blogs.architectingconnectedsystems.com/blogs/cjg/archive/2014/04/... and a sample solution http://code.msdn.microsoft.com/Extending-SharePoint-2013-c39d01ae.
I don't know if you ever tried the following :
- Create and deploy a custom WCF service inside of SharePoint using one of the built-in factories
but if you did, you probably encountered the following problem:
The endpoint /_vti_bin/yourendpoint is not accessible in the context of a SharePoint App
I've been working with SharePoint for quite a few years now in many different environments using both on-premises and Cloud-based solutions and a constant remains : SharePoint development environments are slow...
Here are a few tips that can help to speed up your dev machines.
In this blog post, I'm going to play a dangerous game which consists in comparing two products. Whenever you perform benchmarks, there is always a risk to underestimate some features and to overestimate others. Moreover, since I'm a SharePoint MVP, one could consider that I might not be totally objective in my comparison.
As you know, warmup scripts are used to "wake up" SharePoint so that when the first users are in the office, they don't encounter a very slow page load. On top of waking up the application pools of the web applications, one can also envision to wake up some services.
In a full Windows based authentication, including of course Claims & Windows, it is quite easy to do. However, in a scenario when you have a single zone with multiple authentication providers, say for instance Claims/NTLM-Kerberos & Forms/Custom Membership, things get a little more complicated.
Now that I've been actively involved in two SharePoint migrations from 2010 to 2013, let me tell you what caused me the most headaches and what you'd better not underestimate in case you come yourself to migrate.
I'm not going to talk about refactoring and/or upgrading the code to be more compliant with 2013 except for the extreme situations such as using old legacy SharePoint components. So, most of the comments below are about an "as is" migration and things to consider seriously.
As you might now, SharePoint 2013 comes with a native support of 2010 based solutions & user experience. It ships with two different paths such as:
- Two different GACs. 2010 packages still deploy to the .NET 2/3/3.5 GAC while 2013 packages deploy to the .NET 4 GAC
- Two physical locations for the TEMPLATE folder in 14 & 15
- Some extra virtual directories in IIS to target either 14 (default) either 15 (explicit inclusion)