Stephane Eyskens's blog
In my previous posts on IBM Connections vs SharePoint which you can find here SharePoint 2013 vs IBM Connections 4.5 Social Capabilities - Comparison from the field and here SharePoint 2013 vs IBM Connections 4.5 - Metadata, Office Integration + Mobile support - Comparison from the field, I tried to shed some light on the pros & cons of each platform regarding Social Business & Document Management.
If you read those posts, you might think that I privilege SharePoint over IBM Connections, certainly as a SharePoint MVP. However, it was not the intention, I really tried to make an objective comparison but that kind of exercise is never easy.
The purpose of those posts was to bring some clarity on both products out of a real world experience. I often read here and there *marketing* messages looking like a boxing match between IBM & Microsoft. I must say that IBM is often the first one to bite., maybe because they are in the skin of the challenger in this matter..:? SharePoint is a well known heavy weight for years now...
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.