אנו שמחים להודיע שהחל מהיום מנויי MSDN Premium ו- MSDN Ultimate זכאים לקבל מנוי מפתח ל- Office 365 למשל שנה!

להרשמה להטבה לחצו כאן

הודעה זאת מצטרפת כבר להטבות הקיימות: קבלת מנוי מפתח לאפליקציות Windows Phone וקבלת מנוי מפתח לאפליקציות Windows 8.

עם הרישיון החדש תוכלו לפתח אפקליציות חדשות אשר מרחיבות את הדרך שאנו צורכים מידע ומאפשרות לשלב שירותי ענן ושירותי ווב ולעטוף הכל בממשק המוכר והאהוב של Office ו- Sharepoint.

אתם יכולים לפתח אפליקציות Office באמצעות הכלים, השפה והטכנולוגיה שאתם מכירים. אתם יכולים לפבלש את האפליקציות שפיתחתם ל- Office Store שמהווה marketplace גלובלי המאפשר לקהל הרחב להוריד ולרכוש את האפליקציות שלכם בקלות.

בתור בעלי רישיון מפתח Office 365 אתם זכאים ל:

• אתר SharePoint Online המאפשר לכם לבצע קסטומיזציות ויצירה ובדיקה של אפליקציות
• גישה ל- “NAPA”, כלי הפיתוח של Office 365 המאפשרים לכם יצירת אפליקציה מהדפדפן
• גישה ל- Microsoft Seller Dashboard

 

למדו עוד על פיתוח אפליקציות Office

פיתוח נעים!

2013 כבר כאן, ואיתו בשורות מרגשות לכל משתמשי SharePoint: מודל הפיתוח קיבל תפנית מעניינת והפך להרבה יותר גמיש, חזק, ונגיש על ידי מודל האפליקציות או בקיצור מודל ה- Apps.
בפוסט זה אציג את מודל ה Apps מנקודות המבט *שלכם*. בין אם אתם מפתחים, מנהלי תשתיות, או משתמשי קצה, יש לכם סיבה טובה לאהוב את המודל החדש!
מיד תבינו למה...

אודות Apps

ראשית – הקדמה טכנולוגית קצרה. (אפשר לדלג להמשך אם אתם כאן רק בשביל התובנות, אבל אל תשכחו לפחות לראות את הסרטונים הקצרים האלו).

במהלך השנים מודל הפיתוח ל SharePoint עבר מספר גלגולים. ראשית היו לנו רכיבים שמפותחים בצד שרת, ומשתלבים בסביבת הריצה של SharePoint. אם פיתחנו Web Part קלאסי, הקוד שכתבנו עבורו הורץ כחלק מהתהליך המריץ את SharePoint. צורת עבודה זו הציגה מספר אתגרים בנושאי אבטחה ואמינות - תפקוד לקוי של הקוד שלנו משפיע באופן גורף על השרת כולו.
בגרסת 2010 מיקרוסופט ניסתה לשפר את המצב עם הרעיון של Sandbox Solutions שאומר שהקוד עדיין רץ בשרת, אך לא כחלק מהתהליך שמריץ את SharePoint. רעיון זה התקדם בכיוון הנכון אך הציג אתגרים חדשים בנוגע לפונקציונאליות שהוא מספק ולאפשרויות הפריסה שלו.
בגרסה החדשה (2013) מיקרוסופט לקחה את הרעיונות האלו עד הסוף, ויצרה את מודל ה- Apps.

בבסיס של מודל ה Apps עומד הרעיון שאפליקציות הינן יחידות עצמאיות (ומבודדות) של תוכנה, אשר מתקשרות עם SharePoint, אך למעשה מנותקות לחלוטין מסביבת הריצה שלו.
אם בעבר כתבנו קוד .net שהותקן על ידי מנהל המערכת, בשרת ה SharePoint, והורץ כחלק מאתר ה SharePoint, הרי שכעת כל זה הולך להשתנות.
קוד של אפליקציות (Apps) ב SharePoint 2013 אינו מורשה לרוץ בשרת ה SharePoint. קראו את המשפט הזה שוב, אתם לא הוזים. זהו שינוי רציני וחשוב בשיטת הפיתוח המסורתית.

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

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

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

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

מתכנת

ציינתי שבמודל הפיתוח של Apps הקוד של האפליקציה אינו רץ ב SharePoint אלא בשרת אחר. השילוב של האפליקציה כחלק מהאתר מתבצע על ידי שילוב IFrames ו Javascript שנכתבו במיוחד למטרה זו, והתקשורת עם SharePoint מתבצעת על ידי שימוש בסטנדרטים אינטרנטיים נפוצים כגון REST Services, ו OAuth.

המשמעות היא ש SharePoint תומך כעת בכל פלטפורמת Web שהיא. תהיה זו ASP.net, MVC, PHP כל שרת web יכול לשמש לבניית האפליקציה. זוהי בשורה עצומה למפתחים מכיוון שעד כה פיתוח ל SharePoint הצריך סט מיומנויות ייחודי מאוד, וכעת ניתן לפתח ל SharePoint בכל טכנולוגית web. (כמובן שעדיין, תהליך האריזה של התוצר כ- App של SharePoint מצריך שימוש בכלי הפיתוח של SharePoint, אך זהו לרוב חלק שולי בבניית הפתרון).
בנוסף, גם עבור מפתחי SharePoint ממשקי העבודה הפכו לנוחים ויעילים יותר מכיוון שלצורך הקמת תשתית ה Apps יכולות ה web services המובנים במוצר הורחבו וצורת העבודה איתם הפכה לקלה יותר.

מנהל מערכת

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

משתמש

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

סיכום

SharePoint 2013 מביא את המוצר הוותיק לעידן הנוכחי בו אפליקציות שולטות בעולם הטכנולוגי. אנו רואים זאת מסביבנו במכשירי הטלפון, במחשבים, בטאבלטים, בטלויזיות, באתרי אינטרנט, ועוד...
מיקרוסופט מאמצת את הרעיון ומשלבת אותו במוצריה – Windows Phone, Windows, Xbox, Azure – כולם בנויים סביב מודל פיתוח מבוסס אפליקציות, וכעת גם SharePoint מצטרף לחגיגה כמוצר הראשון שמביא את מודל האפליקציות מעולם ה consumer אל עולם ה enterprise.
הכנסת מודל האפליקציות משחק לטובתכם. בין אם אתם מפתחים, אנשי תשתיות, או משתמשים במוצר – אתם תאהבו את הרעיון ותרצו להשתמש בו.

אני מזמין אתכם להתחיל בפיתוח SharePoint Apps בעצמכם!

• ניתן להוריד גרסת התנסות של SharePoint 2013 בקישור הבא: http://technet.microsoft.com/en-us/evalcenter/hh973397.aspx
  
• בנוסף, ניתן להתחיל לפתח ישירות מול גרסת ה Online של SharePoint בOffice365. ניתן לפתוח חשבון התנסות בחינם, פרטים בקישור הבא: http://msdn.microsoft.com/en-us/library/fp179924.aspx
  
• לסיום, אני מזמין אתכם להירשם לקורס מעמיק בנושא פיתוח ב SharePoint 2013 אשר אנו מעבירים בקרוב מאד. פרטים בקישור הבא: http://www.microsoft.com/israel/promotionalMail/sharepoint/mail3/new/index.html

הפוסט נכתב ע"י איתי שקורי, יועץ בכיר בקבוצת היועצים של מיקרוסופט (MCS) העוסק בייעוץ בתחומי ארכיטקטורה, פיתוח, ו- SharePoint.

הפוסט נכתב ע”י יוני גולדברג, ארכיטקט SharePoint בחברת TOP SOFT , מתמחה בפיתוח מערכות מבוססות תהליכים (Workflow), מייעץ לבנקים, חברות הי-טק וחברות Telco ומרצה קבוע בכנסים בתחום.
עוד פרטים באתר: www.GoldbergYoni.com

ריכזתי מעל 40 טיפים לביצוע Human Workflow מוצלח ואיכותי בסביבת SharePoint, מחולקים ל-4 חלקים:

בחלק 1, 2 ו-3 תמצאו טיפים הקשורים ליישום ללא קוד של פיתרונות, לדוגמא טיפ מספר 5# שעשוי לחסוך לכם זמן רב, או טיפ מספר 7# שממש יכול להציל אתכם ממצב לא נעים וטיפ מספר 15# שיכול לסחוט מהלקוח קריאת התפעלות.

בחלק 4 תמצאו טיפים הקשורים לפיתוח בקוד, שימו לב לטיפ מספר 33# שעשוי ליצור עבורכם פיתרון עם ארכיטקטורה איכותית וקלה יותר לתחזוקה.

• חלק 1 – טיפים ליישום ללא קוד 

• חלק 2 – עוד טיפים ליישום ללא קוד 

• חלק 3 – אפילו עוד טיפים ליישום ללא קוד 

• חלק 4 – טיפים לפיתוח באמצעות קוד

חלק 1 – טיפים ליישום ללא קוד

טיפ מספר 1: ליצירת משימות בתהליך השתמש ב- Custom Task Process

 נתבקשת להקצות משימה לאדם או לקבוצת אנשים באופן סידרתי או במקביל. ב-SharePoint Designer קיימים מספר Actions ליצירת משימה או סבב אישורים. כשמדובר ביצירת משימה בודדת לגורם אחד – אנו עשויים להתפתות להשתמש בפעולות מסוג-COLLECT DATA או ב-Assign a To-Do Item (המוכרים לנו מגירסת 2007) היות והם כביכול מיועדים למשימה פשוטה, אולם גם כשאנו יוצרים משימה לאדם בודד יתכן וסביר שהלקוח שלנו יבקש דברים מורכבים יותר בעתיד כמו: להגדיר SLA (זמן תגובה מקסימלי לאישור משימה), או לאפשר לעובד להעביר את המשימה לאדם אחר. Custom Task Process יוכל לתמוך בכל המצבים האלה ולכן הכי בטוח לצאת איתו אל הדרך. שימוש בפעולה זו תבטיח לך שתוכל בעתיד לתמוך ברוב הדרישות שיעלו.

Start Approval Process ו-Start Feedback Process הם אחים של ה-ACTION הזה וגם הם יוכלו לתמוך במצבים מתקדמים.

הוספת Custom Task Process

טיפ מספר 2: פתח את האתר באנגלית, שנה לעברית לאחר מכן

אם תפתח את האתר עליו הינך עובד בעברית, כל ה-ACTIONS של זרימת העבודה ב-SHAREPOINT DESIGNER יופיעו בעברית. סביר להניח שלא תבין חלק גדול מהתירגומים המוזרים (בחן את עצמך: מה הוא "תהליך משימה מותאם אישית"?...), כשיהיו לך תקלות לא תוכל לחפש במנוע חיפוש עזרה כי כל המידע יהיה בעברית. לפיכך, כדאי לפתוח האתר באנגלית,
ואז במידת הצורך להוסיף את השפה העברית, במקרה כזה ה-ACTIONS ימשיכו להיות באנגלית.

טיפ מספר 3: הגדר שמות של TASK PROCESS באנגלית

כשהינך מגדיר פעילויות של איסוף משוב ומשימה (Start Approval Process או Start Feedback Process או Custom Task Process), בחר את השם באנגלית וללא רווחים. יש לבצע זאת לפני ביצוע ה-PUBLISH הראשוני לזרימת העבודה. מדוע? משום ששם ה-ACTION יקבע את שם סוג התוכן (Content Type) המשוייך לפעולה זו, ואם השם יהיה עברי לדוגמא, יופיעו בשם כל מיני סימנים מוזרים, אחוזים ועוד תווים שאינם נעימים לעין, בנוסף לא תוכל להבין את שמות הטפסים שיווצרו ולא תדע איזה טופס לערוך.

טיפ מספר 4: צור למשתמש ויזואליזציה של מצב התהליך בשתי רמות

מנהל משאבי אנוש מקבל טלפון לבירור: מה קורה עם תהליך הגיוס של העובד החדש שלנו? למה עדיין לא סיימתם? הוא נכנס למערכת, מאתר את התהליך המדובר ומסתכל על המסך. מערכת טובה תיתן לו להבין בשניה את העבר, ההווה והעתיד הפוטנציאלי של התהליך הזה. זוהי מהותה של שקיפות בתהליך. אנחנו רוצים להראות לו תמונה פשוטה שתבהיר לו את המצב – ויזואליזציה של התהליך. ההצעה שלי היא ליצור ויזואליציה ב-2 רמות: (1) איור חצים פשוט שמראה איפה התהליך נמצא כעת, ו(2) איור מורכב של VISIO שמראה בדיוק את התקדמות התהליך שעובר עריכה גרפית.

איור חצים נותן את המבט המהיר והפשוט, הנה איור לדוגמא שמציג למשתמש היכן נמצא התהליך:

חצים להציג למשתמש היכן נמצאת זרימת העבודה

ליד איור החצים הפשוט נשים לינק לתצוגה מורחבת שתפתח את האיור ש-VISIO SERVICES מייצר באופן
אוטומטי. הבעיה היא שהאיור ברירת מחדל שנוצר על ידי VISIO כולל את כל הפעילויות שבתהליך כולל דברים טכניים שלא אמורים לעניין את המשתמש העיסקי (למה שמשתמש במערכת יצטרך לדעת שתהליך ביצע פעולה מסוג Write To History List?), לכן לאחר שנוצרת הדיאגרמה אנו יכולים לערוך אותה ב-VISIO ולעצב אותה כך שתתאים למשתמש העיסקי ותראה רק שלבים רלוונטים. הנה איור של הדיאגרמה לפני ואחרי:

תמונת לפני: ויזואליזציה שנוצרה אוטומטית לתהליך ב-VISIO, המשתמש העיסקי שלך צריך לראות את זה?

אחרי: תמונת ויזואליזציה שנערכה בתוכנת VISIO, הפרטים הטכניים הוסרו, נשארו רק שלבים עסקיים

טיפ מספר 5: איך תפעיל זרימת עבודה לפי SCHEDULE?

לעתים אנו צריכים להריץ זרימת עבודה כל יום או פעם בשבוע. למשל לאחר היווצרות מסמך המתאר מוצר בקטלוג של החברה נרצה בכל שבוע להריץ זרימת עבודה שתיצור למנהל המוצר משימה לעדכן את פרטי המוצר. הדרך הקלה והזולה לביצוע פעולה מסוג זה היא להשתמש במנגנון ה-RETENTION של ה-Information policy management. מנגנון זה מאפשר לנו להריץ זרימת עבודה באופן אוטומטי כל X ימים/שבועות/שנים באופן חוזר.

הגדרת תיזמון לזרימת עבודה

טיפ מספר 6: בפיתוח REUSABLE WF - השתמש במקורות מידע יחסיים

אם הינך מפתח זרימת עבודה לשימוש חוזר (REUSABLE) באמצעות SPD ואתה צריך לקרוא מידע מרשימת המשימות או מרשימת ההיסטוריה – באפשרותך לפנות לרשימות באתר באמצעות שמן, אך אם תעשה זאת וה-WF יופץ לאתר עם רשימות בשם שונה – דברים פשוט לא יעבדו. זרימת העבודה תחפש רשימות שאינן קיימות. לפיכך, באפשרותך לפנות למקור מידע שהוא דינמי, כזה שהוא חלק מההגדרה של זרימת העבודה. בתיבת מקורות המידע עליך לבחור Association: Task List. כעת, אין בעיה שזרימת העבודה תופץ בכמה מקומות ובכל מקום תהיה רשימת משימות עם שם שונה.

שימוש במקור מידע יחסי

טיפ מספר 7: רשימות ההיסטוריה והמשימות נמחקות כל 60 יום!

רבים לפניך כבר נפלו, גם אני נפלתי בפח למרות שקראתי בעצמי את המידע הזה, פשוט הרשיתי לעצמי לשכוח ושילמתי מחיר. מאוד סביר שתציג במערכת דו"חות ומידע מרשימת המשימות או ההיסטוריה. לדוגמא, תרצה להציג את מהלך האירועים בכל תהליך שהתרחש, המשתמש יוכל לאתר תהליך מהעבר ולראות את כל המשימות שהיו בו. שים לב: משיקולים של ביצועים, 60 לאחר סיום זרימת העבודה – כל המשימות והרישומים ברשימת ההיסטוריה נמחקים! כלומר אם המערכת שלך נסמכת על רישומים אילו לצורך תיעוד ההיסטוריה – יתכן שתגלה שנמחקו לך נתונים חשובים. אז מה עושים? (1) ניתן לבטל את ה-TIMER JOB שמבצע פעולה זו, עשה זאת רק אם אתה בטוח שכמויות המידע ברשימות ההיסטוריה והמשימות סביר (2) ברמת השיוך של זרימת העבודה (Workflow Association), ניתן להגדיל את מועד ניקוי במידע לערך גדול. גם כאן, עשה זאת רק אם אתה בטוח שכמויות המידע ברשימות ההיסטוריה והמשימות סביר. (3) העבר בעצמך את המשימות או רישומי ההיסטוריה לרשימת ארכיב, ובדוחות הצג מידע גם מרשימות הארכיב. פעולה זו כמובן תצריך מאמץ פיתוח.

טיפ מספר 8: אינטגרציה קלה עם מערכות חיצוניות

עוד בקשה נפוצה היא לקבל או לעדכן מידע ממערכת חיצונית דרך WEB SERVICE או ישירות מהדטה בייס. SPD אינו כולל ACTION לפניה למערכות חיצוניות (קיים רכיב חינמי ב-CODEPLEX), בקוד זה כמובן אפשרי בקלות (Window Workflow Foundation כולל ACTIVITY מובנה לפניה ל-WS), אך מה נעשה אם איננו רוצים לכתוב קוד? במקרים לא מסובכים מדי, יש פיתרון קל ופשוט: ניצור סוג תוכן חיצוני ורשימת חיצונית (BCS – External Content Type), בדיוק כפי ש-SPD יודע לקרוא ערכים מרשימה רגילה באתר – כך נוכל לקרוא גם מרשימה חיצונית (מידע שמאחורי הקלעים מגיע בזמן אמת ממערכת חיצונית) ואפילו לעדכן/להוסיף/למחוק.

טיפ מספר 9: איך להשתמש באותו טופס InfoPath למשימות שונות

אם תרצה שבכמה סבבי אישור יופיע אותו הטופס (בברירת המחדל SPD מייצר לכל סבב אישורים טופס וסוג תוכן ייעודי) תוכל לעשות זאת באמצעות קובץ הקונפיגורציה של התהליך ידנית. באמצעות SPD נווט ל-

AllFiles-Workflows-[workflow name]-[workflowName].xoml.wfconfig.xml

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

שינוי טופס המשימה של סוג התוכן

עד כאן החלק הראשון בסידרה, אהבת? חלקים 2,3 ו-4 ממתינים לך.