DCSIMG
January 2009 - Posts - itaysk

January 2009 - Posts

Microsoft BI Roadmap Update – SharePoint gets Performance Point

Posted Saturday, January 24, 2009 3:37 AM by Itay Shakury

Microsoft has updated it’s roadmap for Business Intelligence products.
The new roadmap consolidates into SharePoint Server, leaving SharePoint, Excel, and SQL Server the primary components of a BI solution.

image

I have summarized the important notes and implications of this announcement:

  1. Starting today, Businesses that operate under SharePoint Enterprise CAL SA licensing, can use Performance Point Server at no additional cost.
  2. Performance Point Server’s features will be incorporated into future versions of SharePoint Server.
  3. Service Pack 3 for Performance Point Server will be the last investment in Performance Point as a stand alone product. But existing customers will continue to be supported .

In my opinion this strategy relates to recent trends that shows large investments in BI, probably because of the unstable economic situation we are at right now.
By making these changes, Microsoft can help businesses manage themselves better at these times, by reducing the total cost of BI solutions.

Furthermore, I think it is a wise (and predictable) move. SharePoint Server already have BI features such as Excel Services and KPI. Adding Performance Point’s capabilities into SharePoint Server, makes it a complete BI platform, and allows concentrating on development within a single product.

I am looking forward to see what’s coming up.

 

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

with 3 comment(s)
תגים:, ,

Visual studio 2008 extensions for SharePoint 1.3

Posted Monday, January 12, 2009 6:30 PM by Itay Shakury

Visual Studio extensions for Windows SharePoint Services (aka VSeWSS) is out for CTP in a new version - 1.3.

The full list of new features is listed below. Tow annoying frequent developing activities, that now should be easy to do, are the ability to refactor Web Part names, and to include assemblies in the solution manifest.

Personally, I wouldn't use it in large scale projects because it is not flexible enough. Don't get me wrong, I DO think that these solution generators are important and help a lot, it's just that there are plenty of other solutions available on codeplex that I would prefer.

As specified in the official announcement, the new features in VSeWSS 1.3 are:

  • Can be installed on x64 Server OS machines running SharePoint x64. Previously only x86 Server OS could be used.
  • Separate build commands for package, deploy and retract are added.
  • Command line build, package and retract commands are included enabling continuous integration and build servers. Previously command line build of SharePoint projects was very difficult.
  • Refactoring support for renaming of Web Parts. Previously renaming a web part required changes in several files in the project.
  • WSP View improvements for consistency of deleting feature elements, merging features and adding event receivers to features.
  • Solution Generator can now generate solutions from publishing sites. Previously only regular sites could be generated.
  • Allowing partial trust BIN deployments of web parts. CAS configuration must still be provided by the developer.
  • New project item template for SharePoint RootFiles items.
  • Deployment will now optionally remove conflicting existing features on the development server prior to redeployment. Previously any feature name conflicts would result in an error.
  • Ancillary assemblies such as for business logic can now be added to the SharePoint Solution WSP.
  • Hidden features related to Site Definition projects are now shown in WSP View. They are no longer hidden.
  • For advanced users a fast deploy is included to update only the compiled assembly on the SharePoint development installation.
  • The User Guide is now installed with the extensions instead of being a separate download.

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

with no comments
תגים:,

SharePoint Localization

Posted Saturday, January 10, 2009 10:51 PM by Itay Shakury

הרבה פעמים אני שומע תלונות על הגיור של מוצרי מיקרוסופט שונים.. הכוונה היא לתרגום לעברית, ובואו נהיה כנים.. לפעמים זה לא הדבר המושלם בעולם.

אחד הלקוחות שלי, החליט שזה מספיק מספיק מפריע לו, וביקש למצוא פתרון לבעיה ספציפית:
באתרים מסוג בלוג, תירגמו את המילה Comments ל"הערות" (הערה, וכו'). ואכן התרגום שלה לעברית הוא הערות. אך אולי יותר ראוי להשתמש במילה תגובות עבור המנגנון הזה.
אם כן, התבקשתי להחליף את המילים מצורת "הערות" במילים מצורת "תגובות". כמובן שהמילים מופיעות פעמים רבות במקומות שונים בהקשרים שונים.

אני כותב את הפוסט הזה לא כדי להראות איך לבצע את השינוי הספציפי הזה, אלא כדי לתת רעיון כיצד לקסטם את התרגום של SharePoint לעברית, במידה והוא לא מתאים לכם.

בנוסף, אני מראה כאן כיצד לפתור בעיה שנראית נורא קטנה בעזרת המון עבודה. זה אמנם נשמע קצת Overkill, אבל זה הפתרון שנבחר כדי לשמור על תמיכה ועל מודולריות. במקרה הזה, השינויים שמוגדרים כ"unsupported" הם מינוריים מאוד (לדעתי) ואם היה מדובר בשרת שלי למטרות שלי לא הייתי מבצע את הפרוצדורה הרשומה כאן, אלא את האופציה השנייה שרשומה בסוף.

אוקיי, אז ניגש לבעיה שלנו. לכאורה הבעיה נראית קצת מורכבת. אנחנו צריכים להתעסק עם גורמים שונים ומרובים. בין היתר:
Web Parts, Menu Items, Fields, Lists, Links, Views, ועוד..

הנה תמונה שממחישה את ההיקף של שינוי כזה, שצריך לגעת בכל מיני חלקים באפליקציה. (ד"א התמונה נלקחה אחרי השינויים, אז כמו שאתם רואים אין שום אזכור ל "הערות", רק ל "תגובות")
sample

ניגש לעבודה

בעקרון, היינו צריכים עכשיו ללכת לכל המקומות שבהם מופיעה המילה הבעייתית ולחקור את המקור של הטקסט. אני אחסוך לכם את העבודה המייגעת הזו. בסופו של דבר כולם מאיפהשהו ב Site Definition. הגיוני..

אז אילו רכיבים יש ב Site Definition?

ה Site Definition מגדירה בעצם את כל תבנית האתר, בדוגמא שלי היו רלוונטיות הרשימות השונות (List Definitions) ובתוכן השמות של הרשימות ושמות של שדות ברשימות,web parts שמופיעים בדף הראשי ובדפים השני הנשלטים מתוך קובץ onet.xml,ו Features שונים שקשורים.

אם נסתכל כל המקומות הנ"ל ב Site Definition, לא נראה את המילה "הערות" בשום מקום. במקום, נראה שכל ההתייחסות למחרוזות בכלל ולמילה הבעייתית שלנו בפרט, משתמשות בקבצי Resource (קבצי resx).

קבצי Resource של SharePoint

SharePoint, כמו כל אפליקציית .net גדולה אחרת, משתמש בקבצי Resource כדי לנהל את המחרוזות שלו וכדי לנהל תמיכה בשפות שונות.בקצרה: ישנם 3 מקומות עיקריים שבהם יכולים להמצא קבצי Resource ב SharePoint והם מתחלקים לפי השימוש בהם:

  • Site Definitions או List Definitions יכולים להשתמש במה שנקרא Provision Resources. אלו משמשים בזמן תהליך ה Provisioning ולכן רלוונטיים ל Definitions שונים. קבצים אלו נמצאים בתיקיית ה 12 תחת התיקייה Resources.
  • Features יכולים להשתמש בקבצי Resource מקומיים להם והם מוגדרים בתוך ה feature עצמו.
  • בשביל Resources לזמן ריצה, שאר האפליקציה מחזיקה קבצי Resource ברמת ה Web Application ביחד עם שאר קבצי האפליקציה ב IIS. אלו נמצאים בתיקייה שמוגדרת עבור ה Web Application תחת App_GlobalResources.

אני ממליץ לקרוא את ההסבר הזה על Resources ב SharePoint, שמסביר קצת יותר לעומק על הנושא.

סיכום ביניים

אתם עדיין איתי? אוקיי. בואו נסכם מה היה עד עכשיו..

  1. הייתה לנו מילה בעייתית.
  2. חיפשנו את המקור שלה, והגענו ל site Definition.
  3. משם הגענו לקבצי ה Resource ודיברנו עליהם.

יצירת קבצי resource חדשים

אז עכשיו אנחנו יודעים מאיפה הטקסטים האלה מגיעים. יופי! אז אפשר לפתוח את קבצי ה Resources, לחפש בהם את המילים הבעייתיות ולשנות אותן. האמנם?

בעקרון אפשר לעשות את זה. וזה יעבוד מצויין. והנה בא אבל:
שינוי קבצי מערכת של SharePoint הינה פעולה לא נתמכת - not supported, ולכן אינה מומלצת. שוב, זה לא אומר שזה לא יעבוד אבל כדי להיות פוליטיקלי קורקט אנחנו נראה את הפתרון הנכון (והמסובך יותר).

כדי לא לשנות את קבצי ה Resource המקוריים של SharePoint, אנחנו ניצור קבצי Resource חדשים, נוספים, משלנו, ובהם נבצע את השינויים.

ניכנס לתיקיית ה Resources המתאימה. במקרה שלנו, ניגש ל Provision Resources. ניצור קובץ Resource מכיל רשומות חדשות משלנו. הרשומות החדשות שלנו "ידרסו" את הkeys הרלוונטים שגילינו ב Site Definition.

יצירת Site Definition חדש

סבבה, אז יצרנו קבצים חדשים ושינינו בהם את הטקסטים הבעייתיים. אבל איך האפליקציה תדע להתייחס לקבצי ה Resource שלנו, ולא לקבצים המקוריים? היא לא תדע. ולכן אלינו לשנות אותה כדי לעדכן אותה בשינויים.

אז כל מה שנותר לנו לעשות זה לשנות את ההפניות מתוך ה Site Definition לקובץ ה Resource החדש שלנו במקום לישן וזהו. האמנם?
נכון, זה יעבוד. אבל שוב, אנחנו לא יכולים לשנות קבצי מערכת. (או לפחות לא רוצים).

אז מה עושים? יוצרים Site Definition חדש, ונוסף, שיהיה זהה לחלוטין למקורי, מלבד הפנייה ל Resources.
יצירת site Definition היא פעולה מותרת, ובאפשרותנו להעתיק Site Definition קיים וליצור על פיו אחד חדש. ניצור Site Definition חדש על בסיס "Blog" הקיים. פירוט על יצירת Site Definition מאחד קיים ניתן למצוא כאן.

עדכון ה Site Definition

סבבה. יצרנו Resource files חדשים עם השינויים שלנו, ויצרנו Site Definition חדש.

תתפלאו אבל עד כאן זה החלק הקל:)

עכשיו מה שנותר לנו לעשות, זה לעבור על כל רכיבי ה Site Definition, ולחפש את כל המקומות במתייחסים למילה שלנו. בכל פעם כזאת, נחליף את הפנייה ל Resource הישן בפניה לResource החדש.
כמו שאמרתי, וכפי שניתן לראות בתמונה שבתחילת המאמר, המילים יכולים להפיע במגוון רחב של רכיבים. ולכן החיפוש לא יהיה קל.
מה שאני עשיתי זה ללכת הפוך. חיפשתי בקובץ ה Resource את המילה "הערות" ואז גיליתי אילו Keys רלוונטים אלי. עכשיו אפשר ללכת ל Site Definition ולחפש את הKeys שמצאנו, ולשנות את ההפניה, כך שSharePoint תחפש אותם בקובץ החדש שלנו ולא בישן.

אופציה ב'

כפי שציינתי בתחילת המאמר, הפרוצדורה הזאת נראית די מורכבת עבור שינוי כזה קטן. אני הייתי ממליץ לשקול לשנות את קבצי ה resource המקוריים של sharepoint במקום.
בשיטה הזו אנחנו לא צריכים לתחזק קבצי Resources נוספים, לא צריכים ליצור Site Definition חדש.
אם היה מדובר בשינוי קבצי מערכת אחרים, כמו Site Definition, לא הייתי ממליץ לשקול את האופציה הזו, אבל שינוי קבצי ה resource לא נורא כמו שינוי Site Definition.

סיכום

מקווה שנתתי לכם מושג לגבי התאמה של טקסטים ב SharePoint. הדוגמא שנתתי התבססה על דרישה ספציפית מאוד, ולכן קרוב לוודאי שבמקרה שלכם, תידרשו לבצע שינויים נוספים במקומות נוספים, או שחלק מהדוגמאות שנתתי לא יהיו רלוונטיים אליכם.
בכל זאת, מה שחשוב שתבינו, זה העבודה עם Site Definition וResource Files, והרעיון של יצירת עותקים במקום לשנות את הקבצים המקוריים.

בהצלחה בקיסטום שלכם!

 

--שמי איתי שקורי ואני יועץ SharePoint--

with 2 comment(s)
תגים:, ,

A new player in the field of online collaboration

Posted Wednesday, January 07, 2009 12:37 PM by Itay Shakury

Yesterday, Apple has announced a new web based service called iWork.com aimed for online collaboration.

If you wann'a skip directly to the bottom line, I personally don't think it will be a great success, and wouldn't be using it myself.

iWork is a software suite for mac that has been around for a few years. It includes a word processing software called Pages, a spreadsheet software called Numbers, and a presentation software called Keynote.

Today Apple has announced iWork 09 and with it, a new web based service called iWork.com. 

With iWork.com you can share and publish your works for anyone to see and review. Your docs are uploaded to the web, and each user is given a unique URL to access the document. Users can then review and comment about your document. It has support Microsoft Office formats as well, and PDF, so that PC users can use it as well.

iwork_presentation

Here is a video demo that shows how it looks and works:
http://movies.apple.com/media/us/mac/iwork/iwork-dot-com/2009/tutorials/apple-iwork-dotcom-explore_iwork_dotcom-us-20090106_r640-10cie.mov?width=640&height=400

I haven't had a chance to use it, but from what I saw and read so far here is my impression:

  • As expected, the GUI looks very nice and refined, and also very user friendly.
  • I particularly liked the notes feature that allows you to comment on specific parts of a document very easily.
  • I hate the face that you have to use iWork for publishing you docs, and iWork is mac only...
  • I also missed stuff like workflow features or some kind of process management solution for tracking the ongoing work on the document.
  • Also, the service is commercial, and as soon as it leaves it's beta stage, will be a paid service.

conclusion:

I was interested to see Apple jumps into the field of online collaboration, which is dominated mainly be Google and Microsoft who are tow massive players, and offer great products.

With products like Google Docs, and Microsoft Office Live Workspace, I can't see apple fit in with a mac only, commercial product, that isn't offering much more.

Eventually I wouldn't have used iWork even if I could (I'm a PC user).

 

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

with no comments
תגים:, ,