DCSIMG
עמוד הבית| חבילות השירות שלנו| חומר חופשי| צור קשר
June 2010 - Posts - בלוג היועצים של מיקרוסופט ישראל

בלוג היועצים של מיקרוסופט ישראל

June 2010 - Posts

Dynamics CRM 4.0 with Silverlight as a UI Scripter

ניסיון קטן שביצעתי לאחרונה מצא חן בעיני ורציתי לחלוק אותו.

לכאורה שני טכנולוגיות שונות שנראה כי יש אפשרות לשלב ביניהם, האחת הינה Dynamics CRM 4.0 והשנייה Silverlight.

הרי ב- CRM יש אפשרות לשלב אלמנטים בדף כ- IFrames , אז מדוע לא נשלב דף Silverlight המארח Dashboard מגניב בעל גרפיקה ו- Control ים מגניבים ?

אז... כבר ביצעו זאת ויש אין ספור דוגמאות ברשת, אולי בעתיד נפנה לכמה מהן, אך זה לא נושא ה- Post.

היום ברצוני להראות כיצד ניתן להשתמש במנוע ה- Interoperability בין עולם ה- DOM וה- JavaScript לעולם ה- Silverlight , בו אנו כותבים Managed Code ונהנים מיכולות שונות כמו: קריאה לשירותי WCF בצורה קלה ומוכרת ואף מנועי ריצה שונים כגון: Garbage Collection ועוד. מה גם שבצורה הזו נוכל לכתוב את לוגיקת ה- Client Side עם Intelligence מלא וניצול החיבור בין Visual Studio ל- ALM לעבודה בגרסאות, צוותי פיתוח, Build ים ועוד.

ולשם שינוי, אנו נבצע את הדוגמא בצורה שהינה Supported לחלוטין.

ישנם דוגמאות ורעיונות בהן נוגעים בקובץ ה- Global.js ומחברים לכל האפליקציה את ה- Silverlight Control המצביע ל- XAP אחד המכיל לוגיקה. כאמור זה אינו נתמך ולא נדון באפשרות הזו כאן.

השיטה:

· ניצור דף Html פשוט המכיל אובייקט Silverlight המפנה לאפליקציית Silverlight בעלת מתודה המסומנת כ- Scriptable Member

· נבצע Customization לאחת הישויות, לדוגמא Contact

· נוסיף IFrame המפנה לאפליקציית ה- Silverlight

· ונוסיף קוד באחת ממתודות ה- OnChange שנבחר ובה נקרא לפונקציית ה- Silverlight שחשפנו.

לצורך הדוגמא כל שאנו צריכים זה לפתוח Visual Studio לייצר אפליקציית Silverlight הכוללת אפליקציית Web כ- Host.

clip_image001

 

 

 

 

 

 

 

נכריז על MainPage כ- [ScriptableType] ב- Loaded event נרשום את ה- Control כ- ScriptableObject מה שיאפשר לנו להגיע אליו מדף ה- Html. ונחשוף את אחת הפונקציות כ- [ScriptableMember]

לדוגמא:

namespace CRMSilverlight

{

[ScriptableType]

public partial class MainPage : UserControl

{

public MainPage()

{

InitializeComponent();

this.Loaded += new RoutedEventHandler(MainPage_Loaded);

}

void MainPage_Loaded(object sender, RoutedEventArgs e)

{

HtmlPage.RegisterScriptableObject("CRM_SL", this);

}

[ScriptableMember]

public string GetDescription()

{

return "This is my Silverlight Description";

}

}

}

כמו כן בדף ה- Html ניתן ID, ל- Silverlight object לצורך נוחות.

לדוגמא:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%" id="SilverlightControl">

נפרוס את האפליקציה תחת ספריית ה- ISV של CRM , כך:

clip_image002

 

 

ב- CRM נבצע Customization ל- Contact, נוסיף IFrame לדף ה- Html שיצרנו.

clip_image003

 

 

 

ונחבר ל- OnChange של אחד השדות את הקוד הבא:

clip_image004

 

 

 

 

 

 

והתוצאה הינה בשינוי שדה, קבלת ערך מתוך אפליקציית ה- Silverlight

clip_image006

 

 

 

 

 

 

טריק נוסף הוא להוסיף את השורה הבאה ב- Form OnLoad בכדי להסתיר את ה- IFrame

crmForm.all.IFRAME_SL.parentElement.parentElement.style.height = '0px';

וזהו, הראתי דוגמא קטנה לחיבור בין Dynamics CRM ל- Silverlight, וכעת אתם יכולים להשתמש בדמיון לשימושים השונים.

כמה רעיונות: ביצוע validations , תלות בין שדות, קריאה לשירותי WCF ועוד עוד.

System Center Configuration Manager – מה בגרסה הבא?

User-Centric Management – יכולת של צוות IT לנהל סביבת הבודה של משתמש ללא תלות בסוג שלה (מטלפון נייד ועד מחשב בייתי) או סוג רשת שהוא מחובר אליה.

Flexible Delivery of Applications – תכונה שמאפשרת ל SCCM לבחור את הדרך להפצת אפליקציות, בצורת הפצה סטנדרטית או באחד מהדרכים המתקדמות, כמו: Virtual, Mobile, On-presentation. בנוסף יישומים המותקנים מוגנים על ידי מנגנון זיהוי תקלות ותיקון אוטומטי.

On-Demand Applications – פורטל של שירות עצמי המאפשר למשתמשים לבחור יישומים להתקנה.

Unifying Management Tools – קונסול ניהול יחידה לסוגים שונים של התקנים וסביבות שונות של עבודתם. לדוגמה: ניהול שולחן עבודה וירטואלי (App-V, Med-V ו Citrix XenApp) ומכשירי טלפון מבוססים על מערכות הפעלה Windows® Phone או Nokia Symbian.

Integrated Platform – אינטגרציה מובנת עם System Center Client Management Suite שכולל חבר חדש במשפחה - System Center Service Manager.

Legacy Configuration Manager Migration and Support – מיגרציה ישירה של SCCM Sites, Inventory Data, Packages, Collections ו Reports לסביבה חדשה. בנוסף, אפשרות לשמירת מודל ניהול נוכחי ללא צורך לשינוי מיידי לצורת ניהול חדשה ישר לאחר השדרוג.

Self-healing client – זיהוי תקלות ותיקון אוטומטי של SCCM Client.

רוצים לדעת עוד? מידע נוסף:

http://www.microsoft.com/systemcenter/en/us/configuration-manager/cm-vnext-beta.aspx

Dynamics CRM Advanced Developer Extensions

 

ייתכן ולא שמתם לב , אבל בהתקנה של Dynamics CRM SDK החדש קיימת תיקייה בשם microsoft.xrm

תיקייה זו מכילה את מה שמיקרוסופט הגדירה כ - Advanced Developer Extensions  :

  •  Simplified connection to Microsoft Dynamics CRM servers (Microsoft.Xrm.Client)
  •  Code Generation of strong types (CrmSvcUtil.exe, Microsoft.Xrm.Client)
  •  Simplified data modification in Microsoft Dynamics CRM (Microsoft.Xrm.Client)
  •  Supports the use of LINQ to retrieve data from Microsoft Dynamics CRM (Microsoft.Xrm.Client)

 

בעיני זה מפשט מאוד עבודה עם ישויות של CRM  בזכות שימוש ב - LINQ

להלן פוסט של David Yack   שמדגים עבודה עם LINQ   ב - Walkthrough    של 10 דקות (בדקתי - זה לקח ביוק 10 דקות)

שירותי MCS רלוונטיים

Posted: Jun 16 2010, 08:00 AM by georgsa | with no comments
תגים:, ,

ארכיטקט התוכנה ושחקן הכדורגל

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

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

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

2. בכדורגל – שחקן יכול להחליף קבוצות וארצות מגורים בקלות. אין סנטימנטים.
   
ארכיטקט התוכנה צריך לדעת שאין סנטימנטים לטכנולוגיה. תפקידו, כארכיטקט המערכת, הינו לעשות שימוש בטכנולוגיות המתאימות ביותר (לאו דווקא המתקדמות ביותר!), שישרתו את המערכת על הצד הטוב ביותר. ארכיטקט שאומר לעצמו משהו כמו “אני אמליץ לעשות שימוש ב- WinForms כי אני לא יודע כלום על WPF” דומה לשחקן כדורגל שדוחה הצעה מברצלונה כי הוא לא יודע ספרדית.

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

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

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

ארכיטקטורת ענן – למה, כמה והיכן

והתחזית – עננות כבדה (נדוש אה?)

אני שמח לעדכן אתכם על יום עיון בנושא ה"ענן" שמתקיים ב – 30/06/2010 במשרדי מיקרוסופט.

למי ששמע על "הענן" או בשמו העברי ה – Cloud, אבל לא ממש מבין על מה מדובר, זו ההזדמנות ליישר קו - לבוא לשמוע ולהשכיל.
בעצם, גם למי שכן מבין על מה מדובר אבל רוצה לראות דוגמאות, ללמוד על הפלטפורמה ולשמוע על שיקולי עיצוב וארכיטקטורה בענן.

להלן תוכנית האירוע (ולינק לרישום)

clip_image001[4]

תהנו,

טל

תקשורת בין מודולים

clip_image001

[אני מניח שכולכם מכירים את התרשים (ואם לא, כדאי שתכירו) - לקוח מתוך "Architecture and Design Guidelines" באדיבות P&P. ]

מכירים ארכיטקטורת שכבות?

כמובן! מי לא מכיר?
כולנו מכירים ויודעים לדקלם למה יש שכבות, כמה שכבות, איך לממש....

לכולם (אני מקווה) גם ברור שאני לא מאפשר גישה לשכבת ה – DAL ישירות מה – Service Layer או מה – Presentation Layer. (אבל למה? - זהו לא הנושא שעליו אני רוצה לדבר ולכן לא ארחיב...)

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

להלן שיחה בין ארכיטקט (א) לראש צוות (ר):
(ר): אהלן א', בדיעבד, חבל שבאת, יש לי ארכיטקטורה, יש לי עיצוב, הכל לפי best practice של מיקרוסופט.

(א): ומה לגבי השאלה שהעלתה בעבר על האופן בו מודול A מבצע פעולות מול מודול B?

(ר): אין בעייה – מבצע reference ל – Business Component של מודול B מתוך ה – business Component של מודול A ומבצע קריאה לפונקציה שאני מעוניין בה..

(א): חס וכרפס
(ר): אבל למה?

(א): הסיבה הכי פחות מהותית אך הכי פרקטית היא שזה יגרום ל- circular references.

(ר): אין בעייה – שמעתי שיש רכיב מדהים שנקרא unity שמאפשר לקבל "מפע" (instance) ללא reference ישיר.

(א): נכון. אבל ישנן סיבות מהותיות יותרשבגללן לא לנבצע קריאה מ – Business component של מודול אחד ל – Business Component של מודול אחר:
כאשר מעצבים מודול, מחליטים איזו "פעילות" תתבצע בכל רכיב – האם והיכן יתבצע caching, האם ואילו בדיקות קלטים ותקינות יש לבצע וכיו"ב.
על מנת שכל תהליך עסקי יהיה שלם, מודול חושף "נקודת כניסה" (entry point) לצרכנים השונים. כך, כל מי שפונה לקבל שירות מהמודול, המודול מוודא שלמות עסקית.
הצרכנים השונים יכולים להיות שכבות אחרות (למשל UI), אפליקציות אחרות שרוצות לקבל שירות וגם מודולים אחרים.
אם נאפשר שמודול A יפנה ישירות ל – Business Component של מודול B, יתכן ונדלג על בדיקת תקינות נתונים, יתכן ונדלג על בדיקת הרשאות....
בנוסף, פנייה כזו תייצר הדיקות בין שני המודולים ותגביל את יכולת ה- reuse וגם עלולה לגרום לבעיות תחזוקה, שכן, ככל שהממשקים של מודול ל"עולם החיצון" קטנים יותר, יש סיכוי קטן יותר ששינויים בתוך המודול ישפיעו על רכיבים אחרים.

(ר): אוף חבל! אז מה לעשות?

(א): מודול A יקבל שירות ממודול B דרך "נקודות הכניסה", כמו כל צרכן אחר. ואכן, הדרך המומלצת היא לקבל מופע ע"י רכיב factory כלשהוא (כדוגמת Unity) שמספק "מופע" על בסיס interface של מודול B.

- סוף שיחה –

לסיכום:
כאשר אתם מתכננים מערכת, אנא הקפידו, שלכל מודול יש "נקודות כניסה" (על פי המתואר בתרשים לעיל, רכיבים אלו נמצאים ב – Application facade) ושרק דרכו צרכנים מקבלים שירותים מהמודול.

בהצלחה,

טל

 

שירותי MCS רלוונטיים

  • (PDF) שירות ניתוח פערי ארכיטקטורה
  • (PDF) שירותי ניהול מחזור חיים של אפליקציה – ALM