itaysk

A while ago, Microsoft has released a CTP (Community Tech Preview) version for the SDK (Software Development Kit) of the next version of SharePoint (aka SharePoint 15).
I have already discussed Apps in a previous post, but there’s even more to learn from the new CTP SDK.

Disclaimer: This post is my personal take from browsing through the CTP SDK. This is not an official announcement. All the info this post is based upon is publicly available here: http://www.microsoft.com/download/en/confirmation.aspx?id=28768.

SPPageContentManagerb - “Manages all the resource content that may be registered on a SharePoint page, including script files, inline scripts, style files, inline styles, and hidden input fields. Spweb Ensures that the content can be either appropriately placed on a fully-rendered HTML page or correctly transmitted to a browser in the case of a partial page load.”

This class must work closely with this new feature:

MdsCompliantAttribute – “Indicates whether the script, style, and field registrations of a class are compliant with the Minimal Download Strategy (MDS) framework.”

So this is an attribute that can be applied to controls (?), that specifies weather or not the control adheres to “Minimal Download Strategy (MDS)”. Googling the phrase “Minimal Download Strategy” took me to this page that explains what MDS is about: “The minimal download strategy will use a single .aspx file (start.aspx) for your pages, with the actual URL encoded in the text following the hashmark (‘#’). When navigating from page to page, only the changes between two compatible pages will be downloaded. Fewer bytes will be downloaded and the page will appear more quickly.”
So this is some kind of hardcore AJAX, in which all pages are actually a single page, and switching between pages will only load differences (so the chrome stays fixed). I wonder if this will get the same kind of bad reputation that the (pretty similar) UpdatePanel control from ASP.net has got.

Search from Client OM

New namespace called Microsoft.SharePoint.Client.Search.Query that indicates the Client Object Model now supports using SharePoint’s search.
Up until now we could only use web services to do this. Now we have convenient and familiar object model.
The namespace has classes like Query, KeywordQuery (that inharites from Query), and ResultTable. This is similar to what we know from the server OM.
There’s also a new SearchExecutor class that execute the queries (like ClientContext.Execute).

Looking forward to more interesting stuff in SharePoint 15 :)

Disclaimer: This post is my personal take from browsing through the CTP SDK. This is not an official announcement. All the info this post is based upon is publicly available here: http://www.microsoft.com/download/en/confirmation.aspx?id=28768.

-- My name is Itay Shakury, and I’m a SharePoint Consultant --

A while ago, Microsoft has released a CTP (Community Tech Preview) version for the SDK (Software Development Kit) of the next version of SharePoint (aka SharePoint 15).
Browsing through it I have learned about the new concept of Apps in SharePoint 15 (codename). In this post I will share my findings and conclusions.

Disclaimer: This post is my personal take from browsing through the CTP SDK. This is not an official announcement. All the info this post is based upon is publicly available here: http://www.microsoft.com/download/en/confirmation.aspx?id=28768.

I start by noticing the SPApp object, that lies in the Microsoft.SharePoint.Administration namespace. It “Represents an app loaded onto Microsoft SharePoint Server and ready to be installed.”
Right next to the SPApp Object, we see the SPAppCatlog class which “Represents all of the SPAppInstance objects installed on an instance of Microsoft SharePoint Server. It provides querying capabilities for discovering installations.”. Naturally, if we are going to have apps, we need some sort of an App Store to obtain apps from.

If we drill down a level into the SPAppCatalog, we will see that it has a GetAppInstance method, that “Gets all the SPAppInstance objects installed at a given SPWeb.”. Also, the SPAppInstance class says it “Represents an SPApp object installed to a specific SPWeb site.”. So apps are scoped to the SPWeb level – cool.

Continuing to the SPWebApplication class, we find that is has a new method called IsUserLicensedForEntity, that “Checks if the currently logged in user has the proper license to access the specified entity.” If we going to have an App Store like system, we need to have a mechanism to enforce licensing.

What more do we know about apps from real world? They need your permissions to access your data. This is usually done (in real world) with the OAuth protocol, and SharePoint 15 apparently supports this too! There’s a new namespace called Microsoft.SharePoint.IdentityModel.OAuth2 that will probably contain the basis for this, and some classes in Microsoft.SharePoint like SPApplicationCredentials and SPAppPrincipalPermissionsManager that will probably allow programmatic handling of permissions.

There’s another new namespace called Microsoft.SharePoint.Administration.AppDeployment that contains two classes – DatabaseProviderConstants, and DatabaseProviderTypePersistedObject. So there’s apparently something with a database for an app. The SPWeb class also has new properties regarding App DBs – for example the AppDataBaseName property that “Gets the name of the app database associated with this Web.”. Frankly, this is still a mystery for me since it’s use is not documented in the CTP SDK, and not very self explanatory.

In conclusion:

• SharePoint has a new concept of Apps
• Apps are scoped to SPWeb
• Apps are distributed via the AppCatalog
• There’s built in support for licensing apps
• Apps can ask for permission using OAuth
• There’s something with app databases yet to be clarified

This is a very interesting direction that the SharePoint team is taking, and probably revolutionary in the SharePoint world. I hope we can here more details soon.

Disclaimer: This post is my personal take from browsing through the CTP SDK. This is not an official announcement. All the info this post is based upon is publicly available here: http://www.microsoft.com/download/en/confirmation.aspx?id=28768.

-- My name is Itay Shakury, and I’m a SharePoint Consultant --

When you develop a custom timer job, there is often a need to store configuration settings.
The best way to do this is using the Hierarchical Object Store in SharePoint, by creating an SPPerststedObject. There are plenty of articles out there that tell you to how to do this.
For more info on this subject, see this:
http://msdn.microsoft.com/en-us/library/cc406686(office.12).aspx
http://msdn.microsoft.com/en-us/library/hh528519.aspx

So it’s called "hierarchical” object store, because you have to attach the settings to a certain object in the SharePoint object model, and that object must support this by inheriting from SPPersistedObject. Most of those articles shows you how to attach settings to SPFarm, SPWebApplication, or SPSiteCollection objects, but as a matter of fact, the SPJobDefinition class is also a SPPersistedObject!

This means that you can attach settings to the job object directly, and not leave them hanging at the farm or a higher level. This has two benefits:

1. It’s more organized to keep timer job related settings at the timer job level (and not web application level for example)
2. When you delete the timer job, the settings are deleted as well

Here’s a sample:

   1: SPWebApplication wa = SPWebApplication.Lookup(new Uri("http://MySP"));

   2: SPJobDefinition job = wa.JobDefinitions.First(j => j.Name == "MyTimerJob");

   3:  

   4: //Store the settings

   5: MyJobSettings settings = new MyJobSettings("settings", job); //here we set job as the parent

   6: settings.settings1 = "Sample Data";

   7: settings.Update();

And the reading:

   1: //Read the settings

   2: MyJobSettings res = job.GetChild<MyJobSettings>("settings");

   3: string setting1 = res.setting1;

-- My name is Itay Shakury, and I’m a SharePoint consultant --

בכנס SharePoint Extreme האחרון העברתי מצגת על Claims Based Authentication עם SharePoint 2010.
מכיוון שזהו נושא חדש יחסית, המצגת התמקדה בעיקר בהיכרות עם מה זה בכלל Claims Based Authenticatoin, ואיך זה עובד.
לאחר המצגת קיבלתי שאלות בנוגע לתהליך הטכני. פוסט זה בא להבהיר את התהליך.

התהליך שהצגתי הוא כזה:

1. משתמש ניגש לשרת SP
2. המשתמש מופנה ל STS
3. STS מאמת את המשתמש
4. STS מחזיר למשתמש Token
5. המשתמש ניגש אל ה SP, הפעם עם ה Token
6. SP מאשר את ה Token ומאפשר גישה

השאלה העיקרית הייתה בנוגע לשימוש ב Cookies, ואיך כל זה עובד עם מגבלות כמו Cross-Domain.

הדרך שבה זה עובד בצורה טכנית היא כזו (מספרי השורות תואמים לשלבים שתוארו מקודם):

1. משתמש מבצע HTTP GET ל SP
2. SP מחזיר 302 Redirect. בסופו של דבר המשתמש מופנה אל הכתובת של ה STS (בד”כ סדרה של הפניות)
3. הדפדפן ניגש אל ה STS, המשתמש מאומת באמצעות דף ה Login
4. ה STS מחזיר למשתמש דף שמכיל את ה Token (בגוף הדף, בד”כ כ hidden field),
5. באותו דף ישנו קוד Javascript שגורם לדפדפן לעשות HTTP POST אל ה SP, עם ה Token.
6. SP מקבל את הבקשה ויודע לנתח אותה בהתאם

אם כן, השאלה הבאה היא איך Cookies נכנסים לתמונה?

ה STS, או ה SP יכולים להשתמש ב cookies (או באיזו טכנולוגיה שהם רוצים) כדי לשמר session עם המשתמש.
כלומר, כדי שתהליך ההזדהות לא יקרה בכל פעם, ה SP מנפיק למשתמש cookie שמשאיר אותו מזוהה במהלך השימוש שלו באתר (ע”ע FedAuth).
באותה מידה ה STS יכול להנפיק למשתמש cookie כדי לזהות בצורה אוטומאטית את המשתמש אם הגיעה בקשה נוספת להזדהות.

ביום שלישי הקרוב עד יום חמישי, 13-15/3/2012, יתקיים כנס SharePoint Extreme – כנס מקצועי לחלוטין עם הרצאות ממוקדות לקהלי יעד שונים בנושאי SharePoint.
אני ארצה ביום חמישי במסלול Real World SharePoint Architecture הרצאה על Claims Based Authentication ב SharePoint 2010.
בהרצאה אציג את העולם של Claims Based Authenticatoin, את היתרונות והמניעים לטכנולוגיה, את השילוב עם SharePoint, ותרחישים לדוגמא שמתבססים עליה.

(ההרשמה לכנס כרוכה בתשלום)

לפרטים נוספים והרשמה:
http://www.microsoft.com/israel/sharepointExtreme/content/Lectures/13036.aspx